things I have written about 
elsewhere #20200110 


Map updates, 2019 - 2020 


Map updates, 2019 - 2020 





Leaflet | © OSM contributors | Nextzen | Who's On First | SFO Museum. 


The 747 in this picture is not really a "proposed museum extension". Personally I would love it if it were but so far 
there's only one other person around here who supports the idea (and they think the museum should have two 
airplanes!) 


This was originally published on the SFO Museum Mills Field 
weblog https://millsfield.sfomuseum.org/blog/2020/01/10/ 


map/ ,in January 2020. 


We've updated the historical aerial 

maps https://millsfield.sfomuseum.org/map/ section of the 
Mills Field https://millsfield.sfomuseum.org/ website to 
include imagery from 

2019 https://millsfield.sfomuseum.org/map/#2019 .Like 
2017 https://millsfield.sfomuseum.org/map/#2017 and 
2018 https://millsfield.sfomuseum.org/map/#2018 _ this is 
imagery that goes all the way down to zoom level 20 so the detail is 
pretty great. 


Here's the recently opened observation 

deck https://millsfield.sfomuseum.org/observationdecks/1 
477855925/ onthe G side of the International 

Terminal https://millsfield.sfomuseum.org/terminals/1477 


855833/ 





This imagery was produced during the first half of 2019, before 
construction on the new 

hotel https: //millsfield.sfomuseum.org/buildings/14778560 
05/_ or the new Terminal 

1 https://millsfield.sfomuseum.org/terminals/1477855657 


/ was completed. 





Leaflet | © OSM contributors | Nextzen | Who's On First | SFO Museum 
https://millsfield.sfomuseum.org/map/#2019/19/37.61290/-122.39404 


We've made some user interface and user experience improvements 
to the map by moving "controllers" on to the map itself. These 
include the controls for selecting which year to show and whether 
to foreground or background that imagery. 


These changes allow the map itself to be larger without pushing the 
controls for changing the map's state to a place where you need to 
scroll to access them. This is especially important in a mobile 
context. There are still some improvements to be made for smaller 
devices but overall these changes represent a big improvement 
especially for tablet-sized devices. 





https://millsfield.sfomuseum.org/map/#2019/19/37.61139/-122.38554 


We've added two new map controls as well: One to display the map 
in your web browser's fullscreen 


mode https://developer.mozilla.org/en- 


US/docs/Web/API/Fullscreen API and another to generate a 


static image of whatever is in the map's viewport. 


Technically, the second control has been present since we updated 
the map in late 

2019 https://millsfield.sfomuseum.org/blog/2019/11/06/ma 
ps/ __ but that version was a rough prototype and this version is 
designed to play nicely with Leaflet https://leafletjs.com/ 
(the code that handles drawing the map) so it seems fair to call it 


new . 


Here's a picture of SFO in 
2016 https://millsfield.sfomuseum.org/map/#2016/20/37.61 
384/-122.38740 shown in fullscreen mode, along with the output 


of that view rendered as a static image: 





Fullscreen mode on large displays is great fun and fullscreen mode 
on small displays is incredibly useful since screen space is at a 
premium. The ability to screenshot the map is also great fun and an 


incredibly useful tool for focused investigation and capturing 


details. 





All of the heavy-lifting generating static images is handled by 
Mapbox's leaflet-image https://github.com/mapbox/leaflet- 
image and Eli Gray's 

FileSaver.js https://github.com/eligrey/FileSaver.js/ 
JavaScript libraries. We've written a Leaflet.Control 

handler https://github.com/sfomuseum/leaflet-image- 
control for quickly adding screenshot functionality to any map 
like this: 


var map = L.map("mapid"); 


var image _ opts = { 


on_success: function(map, canvas) { 
var name = "map-1280.png"; 


canvas.toBlob(function(blob) { 
saveAs(blob, name); 


dF 


yi 


var image_control = new L.Control.Image(image_opts); 
map.addControl(image_control); 


The source code is available from our GitHub 
account https://github.com/sfomuseum/leaflet-image- 


control and we'd welcome any feedback or contributions. 


To wrap up, here are a couple screenshots of some related work that 
is both in- 

progress https://millsfield.sfomuseum.org/blog/tags/iii 

f and hiding in plain sight 

if https://millsfield.sfomuseum.org/exhibitions/122660617 
3/images/ 

you https://millsfield.sfomuseum.org/exhibitions/1159160 
129/images/ 

know https://millsfield.sfomuseum.org/exhibitions/12266 
20513/images/ 

where https://millsfield.sfomuseum.org/exhibitions/13774 
62859/images/ 

to https://millsfield.sfomuseum.org/exhibitions/122660337 
5/images/ 

look https://millsfield.sfomuseum.org/exhibitions/1159160 


649/images/page2 
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2020-01-10 


1,000 generations 


the voice from above 


the voice from above 





I've forgotten where I first came across the phrase "the voice from 
above https://www.flickr.com/photos/straup/albums/721576 


26198639192 ".Itis taken from a quote by the French architect Le 


Corbusier https://en.wikipedia.org/wiki/Le_ Corbusier 
following his first plane flight over the city of Paris. The quote in 


full reads: 


Until then men had been aware of one voice only 
from above — bellowing or thundering — the voice of 


the storm. 


It was around the time that 

geotagging https://blog.flickr.net/en/2006/08/29/geotaggi 
ng-one-day-later/ was focus of work at Flickr and it became a 
passage that found its way in to a lot of presentations on the 
subject https: //www.aaronland. info/weblog/2008/05/17/good 
/#thursday . It was also the time when Flickr started treating 
airports as 

localities https: //www.aaronland. info/weblog/2008/07/27/inv 


isible/#corrections 


Very quietly, last May, we updated the reverse- 
geocoding logic to stop looking for the nearest town 
when a photo is geotagged at an airport and instead 
treat the airport itself as the town [to reflect their 
evolution] from being simple gateways to captial-P 


places with their own culture, norms and gravity. 


Geotagging things was the catalyst for a lot of personal work 
around stylized dot maps https://www.flickr.com/search/? 
sort=date-taken- 

desc&safe_search=l&tags=modestmaps&user_ id=35034348999%40 
NOlsview_all=1 of satellite imagery to contextualize things 
which produced the "cluster 

map https://www.aaronland.info/weblog/2008/07/27/invisi 
ble/#historybox " books for travel photos and the "untitled 
intimacies https: //www.aaronland. info/weblog/2009/03/14/b 
uckets/#intimacies "pictures for Twitter posts. It was still a 
time when the first reaction to technologies like geotagging and 
location services wasn't to automatically imagine the worst case 
scenario https://www.aaronland. info/weblog/2015/02/24/eff 


ort/#holodeck 





Fast forward to last week when we released a 
thing https://millsfield.sfomuseum.org/blog/2020/01/10/ma 
p/ atthe museum https://sfomuseum.org/ which is what 


made the following possible 1,000 generations after Flickr. 
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2020-01-13 


a similar vein 


not so much about it 


not so much about it 


@9@ Directions 4 | OQ spiral jetty Transit Satellite 











I like to imagine that everyone in San Francisco enjoys the loop-de- 
loop overpass in to the United maintenance facility at SFO as much 
as I do. Perhaps the attraction simply that it is industrial echo of 
Robert Smithson's Spiral 

Jetty https://diaart.org/collection/spiraljettyaerials 
project on the Great Salt Lake in Utah. 





@ © @ Directions 4 | QsFo fay Transit 
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The maintenance facility itself predates Spiral Jetty by at least a 
decade https://historysmc.pastperfectonline.com/photo/7A 
78CD0E-9C88-46B7-940B-304702641458 but I haven't tracked 
down the exact date when the overpass was added so maybe it's 
always been a shout-out to Smithson's work. In a similar vein to the 
last 

post https: //www.aaronland. info/weblog/2020/01/13/generat 
ions/#voice here are some things I made not so much about the 


overpass but with it. 
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things | have written about 
elsewhere #20200124 


Flight data at SFO and SFO Museum - 1.17 million... 


Flight data at SFO and SFO 
Museum -— 1.17 million flights later 


NOW! FLY TWA JETS! 
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timetable: TWA (Trans World Airlines), Paper, ink. Gift of David A. Abercrombie, in memory of Stanley A. Abercrombie , SFO Museum 
Collection, 2001 .039.770 


This was originally published on the SFO Museum Mills Field 
weblog https://millsfield.sfomuseum.org/blog/2020/01/24/flightdata/ , 


in January 2020. 


A little over a year ago we announced that we had started to collect flight data for 
every flight in and out of SFO in a blog post titled Capturing flight data at SFO 
and SFO 

Museum https://millsfield.sfomuseum.org/blog/2019/01/18/flights/ .A 
few months later we supplemented that work with improved aircraft information 
and flight paths, detailed in a blog post titled Harvey Milk Plane Has a Permalink 
— Updated flight data at SFO 

Museum https://millsfield.sfomuseum.org/blog/2019/05/17/flights/ 





REPUBLIQUE FRANCAISE 





FIRST AIRBUS FLIGHT 


TOULOUSE-NEW YORK 
DECEMBER 22, 1984 





https://millsfield.sfomuseum.org/objects/1511922419/ 


airmail flight cover: Pan American World Airways, Airbus, Toulouse - New York route, Paper, ink, adhesive. Gift of the Pan Am Association, 
SFO Museum Collection, 2000.058.1185 ac https://millsfield.sfomuseum. org/objects/1511922419/ 


As of January 2020 we continue to collect flight data every 

day https://millsfield.sfomuseum.org/flights/ and publish it as open 
data https://github.com/sfomuseum-data?utf8=%E2%9C%9 3&q=s fomuseum- 
data-flights-stype= .So far, we've collected over 1.2 million flights in and out 
of SFO since January 2019! Each one is recorded as a Who's On First -style 
GeoJSON 

document https://millsfield.sfomuseum.org/blog/tags/whosonfirst with 
a stable and permanent identifier, hierarchies specific to that flight and pointers to 
all the 

places https://millsfield.sfomuseum.org/blog/2018/08/28/whosonfirst/ 
and 

airports https://millsfield.sfomuseum.org/blog/2018/10/30/airports/ 
and 

airlines https://millsfield.sfomuseum.org/blog/2018/12/03/airlines/ 

and 

aircraft https://millsfield.sfomuseum.org/blog/2018/12/03/airlines/ 


involved with that flight. 





MAIDEN FLIGHT 


Rand. nS Pb 
747- JUMBO JET 












747 Maiden Flight Details 
Aircraft . Clipper Young America” 
Pilot and Captain ii 

No, of Pascua Robert mM, Weeks 
Hee Total es 
ee NewYork — 1.59 local time 


Cruising Speed" 22°4@"y, 1970 











Height 625 m.p.h. 
Arrive 33,000 ft, ——— 
London 14.07 local time Sree Sct 
TLEY, Hants. 
2EA 


airmail flight cover: Pan American World Airways, Boeing 747, New York - London route, Paper, ink, adhesive. Gift of the Pan Am Association, 
SFO Museum Collection, 2000.058 1185 ac 


The number "1.2 million flights" is a little misleading since it is inclusive of 
"codeshares https://en.wikipedia.org/wiki/Codeshare agreement " where 
one airline operates the same flight (as in a plane with seats in the sky) on behalf of 


one or more other airlines. 


For example if you are flying from 
Auckland https://millsfield.sfomuseum.org/airports/AKL/flights/ to 


Houston https://millsfield.sfomuseum.org/airports/IAH/flights/ you 
might first cross the Pacific Ocean on flight 

NZ9816 https://millsfield.sfomuseum.org/flights/Nz9816/ ,an Air New 
Zealand https://millsfield.sfomuseum. org/airlines/1159283697/flights 
/ plane to San Francisco. From there you'd transfer to flight 

NZ9194 https://millsfield.sfomuseum.org/flights/NZ9194/ which is 
really flight 


UAS505 nttps://millsfield.sfomuseum.org/flights/1527914345/ ona 


United 
Airlines https://millsfield.sfomuseum.org/airlines/1159285413/flights 


/ plane to Houston. 


Your ticket says NZ9194 but you're really on UA505. That's codesharing and it 


happens a lot but there were still over 769,250 actual flights (as in a plane on the 
runway) in and out of SFO in 2019! 


F277 fate 23, 17 rt 


Lochhead Constolions 





menu: Pan American World Airways, Historic First Flights series, Lockheed L-049 Constellation, Paper, ink. Gift of Thomas G. Dragges, SFO 
Museum Collection, 2001.080.201 


These data aren't necessarily interesting in the moment. These data become 
interesting over time when there are a lot of them to coral in to unexpected patterns 
and the proverbial shape of the 

elephant https://en.wikipedia.org/wiki/Blind_men_and_an_elephant 

Their value comes from being able to look back and see things the then-present 
never imagined. The challenge when you want to look back at past data is often that 
no one thought it worthwhile to collect at the time or to give it a safe and patient 
home where the future might find it in the...well, future. 


Our project to collect flight data is part of a larger effort. How and where do we 
keep the data internally? How and where do we make it available to the public? 
How do we do these things in such a way that it doesn't become a burden for staff 
and resources? Every six months or so I spend a day or two revisiting and 
improving the tools and infrastructure we've set up to harvest and publish flights 
but otherwise the entire workflow is automated and doesn't need any babysitting 


from me or anyone else at the museum. 
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AMBASSADOR ECONOMY/COACH SECTIONS C..6,F.G,H 


brochure: TWA (Trans World Airlines), Boeing 747, Paper, ink. Gift of the William Hough Collection, SFO Museum Collection, 2006.010.545 


"A day or two" is still a precious commodity in a museum where available staff 
time is a limited resource. The effort to collect these flight data is not nothing. 
However, when you consider the amount of time it would take to do the same work 
retroactively, with uncertain results at best, coupled with the fact that these efforts 


ensure data is also collected going forward it seems to me like time well spent. 


The cultural heritage sector needs more infrastructure to automate the work that 
would never be left to staff to do by hand because of time and cost. We need those 
systems to be stable and, with a little bit of investment upfront, inexpensive. These 
are not insignificant challenges but the work we're doing around flight data is one 


attempt to address those concerns and to make them viable. 


Returns To Hawaii 
November 20, 1987 















airmail flight cover: Pan American World Airways, Boeing 747, Paper, ink, adhesive. Gift of the Pan Am Association, SFO Museum Collection, 
2000.058.1185 ac 


Today we are happy to announce that we've published the flight data for all of 


2019 https: //github.com/sfomuseum-data? ut f 8=%E2%9C%93&q=sfomuseum- 


data-flights-2019- asa single downloadable SQLite database file: 


https://millsfield.sfomuseum.org/distributions/sqlite/sfomuseum-data-flights- 
2019- 
latest.db.bz2 https://millsfield.sfomuseum.org/distributions/sqlite/sfo 
museum-data-flights-2019-latest.db.bz2 


That file is 1.5GB compressed and 10GB uncompressed so you may want to be careful where you download it from. 


SQLite https://sqlite.org/index.html is a small and fast relational database 
with a rich set of features that has been ported to nearly all operating systems and is 
supported by a long list of programming languages. Unlike other databases which 
store data across a number of files and folders SQLite databases are entirely self- 


contained in a single file. 


The SFO Museum 2019 flight data database contains 1,513,571 records spanning 
1,171,680 flights (which constitute 1,507,230 records when you include flight paths 
and other "alternate" geometries for those flights). 





negative: San Francisco International Airport (SFO), inaugural TWA (Trans World Airlines) Boeing 747 flight, Negative. Transfer, SFO Museum 
Collection, 2011.032.2236 


The other 6,341 records are the data from the sfomuseum-data- 

architecture https://github.com/sfomuseum-data/sfomuseum-data- 
architecture ,Sfomuseum-data-enterprise https: //github.com/sfomuseum- 
data/sfomuseum-data-enterprise , sfomuseum-data- 

aircraft https://github.com/sfomuseum-data/sfomuseum-data-aircraft and 
sfomuseum-data-whosonfirst https: //github.com/sfomuseum- 
data/sfomuseum-data-whosonfirst repositories. These data are included with 
the database because the flight data will reference some or all of their records and 
we want people to be able to retrieve all the related and contextual information for 


flights at SFO in a single download. 


Eventually we will produce blended (or "combined") SQLite databases for all of 
our collections-related metadata https: //github.com/sfomuseum- 
data/sfomuseum-data-architecture . As with all our open data releases this data 


is licensed using the Linux Foundation's Community Data License Agreement 


(Permissive) https://cdla.io/# 


The data is stored in five tables reflecting the Who's On First -ish 
nature https://millsfield.sfomuseum.org/blog/tags/whosonfirst of the 


documents: 


e ancestors -— This table contains all the hierarchical information for 


a given record. 


e concordances - This table contains pointers to other identifiers 


used for a given record. 


e geojson — This table contains the raw (text) GeoJSON data for a 


given record. 


e names — This table contains 
exonyms https://en.wikipedia.org/wiki/Exonym_and_endonym 
or toponyms https://en.wikipedia.org/wiki/Toponymy ind 
variety of languages. There aren't any additional names, beside the 
default English name, for flights but there are for the other placetypes 


in the database.. 


e spr.-— This table contains the "standard places response" (SPR) data 
for a given flight. SPR data is a minimum set of properties guaranteed 


to be common across all records. 





District Sales Manager 
BOAC 
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airmail flight cover: BOAC (British Overseas Airways Corporation), first polar flight, Paper, cardstock, ink. Purchase, SFO Museum Collection, 
2010.221.001 


What you do with a database full of flights is up to you. For example, I queried the 
data directly to count the number of not-codeshared flights: 


$> sqlite3 sfomuseum-data-flights-2019-latest.db 
sqlite> SELECT COUNT(id) FROM geojson 
WHERE 
json_extract(json(body), '$.properties.sfomuseum:placetype') = "flight" 


AND 
json_extract(json(body), '$.properties.flysfo:base_airline') != 


i 


769250 


The easiest place to get started is probably Simon Willison's 
Datasette https://datasette.readthedocs.io/en/stable/ tool, which 


describes itself as: 


...a tool for exploring and publishing data. It helps people take data of 
any shape or size and publish that as an interactive, explorable website 


and accompanying API. 


Datasette is aimed at data journalists, museum curators, archivists, local 
governments and anyone else who has data that they wish to share with 
the world. It is part of a wider ecosystem of tools and plugins dedicated 


to making working with structured data as productive as possible. 


Once you've installed Datasette you can start it up with the flight data like this: 


$> datasette ./sfomuseum-data-flights-2019-latest.db --config sql_time_limit_ms:3600 


And then you can start to query the data in your web browser. For example, all of 
the British 


Airways https://millsfield.sfomuseum.org/airlines/BA/flights/ flights 


involving JFK https://millsfield.sfomuseum.org/airports/JFK/ 


sfomuseum-dataights-2019-late 





< Cc @ © © bocathost:s001/sf Bo © | Q Search +MNOQs#osh @ = 
home / sfomuseum-data-flights-2019-latest 


| spr 

2,858 rows where name contains "JFK" and name starts with "BA" 
name contains ~ JFK 
name starts witty BA 


column = = 


‘\ View and edit SQL. 


This data as json, CSV (advanced) 


id Parent_id name placetype country repo latitude longitude —_min_latitude _min_longitude max_latitude _max_l 

1360738477 1159157791 BA2466 event us sfomuseum- 37.618243 -122.381907 37.61799  -122.370943-37.618243-73.7E 
(FK- data-flight- 
SFO) 2019-01 

1360740233 1159157651 BA4347 event us sfomuseum- 37.61792 -122.38212 37.61799 — -122.970943-97.61792 -73.78 
(FK- data-flight- 
SFO) 2019-01 

1360741299 1159157795 BA4330 event us sfomuseum- 37.618164 -122.381022 37.6179 _-122.370943-37.618164 —-73.7E 
(FK- data-fight- 
SFO) 2019-01 

1360741909 1159157791 BA4316 event us sfomuseum- 37.618243 -122.381907 37.61799 — -122.370943-37.618243—-73.7E 
(SFO- data-fight- 
JFK) 2019-01 

1360742109 1159157651 BA1705 event us sfomuseum- 37.61792 -122.38212 37.6179 -122.370943-97.61792 -73.78 


Jcathost:8001/sfomuseum-data-fights-2019-letest/spr2name_startowith=BASname_contains=JFKA.sort=lattude 


Or all of the flights in and out of Gate 

G97 https://millsfield.sfomuseum.org/gates/1159157683/ (before the 
new Terminal 1 https: //millsfield.sfomuseum.org/gates/1477855901/ 
was opened and before Gate G97 became Gate 

G8 https://millsfield.sfomuseum. org/gates/1477930477/_ ). 


sfomuseum-data-tights-2019-late: 





€ ee © © localhost:8001/sfomuse + @ | Q search +MmOQ#OO0S HO = 


home / sfomuseum-data-flights-2019-latest 


| ancestors 


4,500 rows where ancestor_id = 1159157683 
ancestor_id = 1189187683 
column - . 

‘% View and edit SQL 


This data as json, CSV (advanced) 


Link  rowid id ancestor id ancestor _placetype lastmodified 
12 12 1360738041 1159157683 venue 1548187082 
16 16 1360738043 1159157683 venue 1548187082 
774 774 ~~ 1360742923 1159157683 venue 1548187116 
4550 1550 1376811029 1159157683 venue 4548791536 
5339 5839 1376811203 1159157683 venue 1848791538, 
5579 8579 1376811215 1159157683 venue 1548791538 
6758 6758 1376808045 1159157683 venue 4548791508 
11817 11817 1360743437 1159157683 venue 1548187186 
15609 15609 1376811685 1159157683 venue 1548791544 
19706 19706 1376811877 1159157683 venue 1548791548 
21493 21493 1376808733 1159157683 venue 1548791510 
24458 24458 1376812099 1159157683 venue 1548791553 
26939 26939 _ 1360744139 1159157683 _ venue 4548187107 


In a similar vein we've made sure that our SQLite database works with the Who's 
On First Browser 


tool https://whosonfirst.org/blog/2019/12/20/browser/ which describes 


itself as: 


...a web application written in the Go programming language for 
rendering known Who’s On First (WOF) IDs in a number of formats 
including HTML, SVG, PNG and GeoJSON. It uses Bootstrap for 
HTML layouts and Leaflet, Tangram.js and Nextzen vector tiles for 
rendering maps. All of these dependencies are bundled with the tool and 
served locally. With the exception of the vector tiles (which can be 
cached) and a configurable data source there are no external 
dependencies. It is designed to work locally and remotely, including 
other people’s cloud services, with a variety of Who’s On First 
datasources. 


The Who's On First Browser builds on work we discussed in an earlier blog post 
titled Using the Placeholder Geocoder at SFO 


Museum https://millsfield. sfomuseum.org/blog/2019/11/04/placeholder 


/ around the idea of self-contained and locally hosted web applications. 


Unlike Datasette the Who's On First Browser does not currently support search 
functionality. It will support searching one day in the future but right now it's 
probably not the right tool for someone who wants to casually browse or 
"spelunk https: //whosonfirst.org/blog/2015/09/28/spelunker-jumping- 


into-who-s-on-first/ " their way through the data. 


As mentioned above the Who's On First Browser is a tool for rendering the 
geometries and properties of known records, including their "alternate" geometries 
in a number of different formats. These include a human-friendly web page as well 
as endpoints for returning raw GeoJSON data and for rendering that data as SVG or 
PNG images. 


The Who's On First Browser tool is available from the Who's On First GitHub 
organization https://github.com/whosonfirst/go-whosonfirst—browser- 
sqlite and only requires the Go programming 

language https://golang.org to use. Once you've downloaded the tool you 


can start it up like this: 


$> cd go-whosonfirst-browser-sqlite 


$> go run -mod vendor cmd/whosonfirst-browser/main.go \ 
-enable-all \ 
-reader-source 'sql://sqlite3/geojson/id/body?dsn=sfomuseum-data-flights-2019-latest.db' \ 
-nextzen-api-key {NEXTZEN_APIKEY} 


Then you can start to look up known IDs. For example, Alaska 

Airlines https://millsfield.sfomuseum.org/airlines/1159283813/ flight 
AS1925 https://millsfield.sfomuseum.org/flights/As1925/ from Los 
Angeles https://millsfield.org/airports/LAx/ to San 

Francisco https://millsfield.org/airports/sFo/ on October 15, 

2019 https://millsfield.sfomuseum.org/flights/2019/10/15/_ .Its 
permanent ID is 


1495160039 https: //millsfield.sfomuseum.org/id/1495160039/ 


This is what it looks like in the Who's On First browser when you visit 
http://localhost: 8080/id/1495160039 in a web browser: 


Who's On First Browser 
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LLeattat | Tangram | © OpenStreetMap contributors | Nextzen 


AS1925 (LAX-SFO)'s Whos On First ID is 1495160039 and its relative URI is 149/516/003/9/1495160039.geojson. 


It is a event in US. It is parented by DS8B (2019) 


Its bounding box is 33.942593, -122.370943, 37.617921, -118.38951 


Its principal centroid is 37.617921, -122.38181 


We no longer believe this record to be current 


y src 

geom flysto 

geom_alt swim-route 
swim-path 
‘swim-approach 

y wof 

belongsto Boarding Area D (2019) 


D58B (2019) 

‘San Francisco International Airport 
California 

North America 

United States 

‘San Francisco 

San Francisco County 

‘SFO Terminal Complex (2019) 
Terminal 2 (2019) 

94128 


San Mateo County 


show raw 


>» date 
> edtf 

> flysfo 
» geom 
» icao 
> iso 

> Ibl 
>mz 

» sfomuseum 
> SIC 

> swim 


> wot 


The screenshot above is actually cropped because the list of properties on the left 


hand side is very long images/lax-sfo.png . Most property lists are collapsed 


by default but here's what the £1 ysfo and icao properties look like for flight 


AS1925: 


> date 


> edtf 

v flysfo 

airline AS 

date 2019-10-15 
event arrival 
flight_number 1925 

gate 58B 
journey LAX-SFO 
terminal 2 
timestamp 1571180400 
» geom 

y icao 

aircraft A320 
airline ASA 
base_airline 


Here's a screenshot of the raw GeoJSON and rendered HTML data side by side: 


vy src 
geom 


geom_alt 


y Wot 


belongsto 


breaches 


concordances 


country 
created 
geomhash 


hierarchy 


flysfo 
swim-route 
swim-path 


swim-approach 


Boarding Area D (2019) 
DS58B (2019) 

San Francisco International Airport 
California 

North America 

United States 

San Francisco 

San Francisco County 

SFO Terminal Complex (2019) 
Terminal 2 (2019) 

94128 


San Mateo County 


swim:flight_ref 116480574 


US 
1571241755 
602be2a828e3460cadf44beSbic2e36b 


building_id SFO Terminal Complex 


(2019) 


San Francisco 
International Airport 


campus_id 


show pretty 





"date: cessation_lower" 
"date: cessation_uppe! 
"date: inception_lower" 
"date: inception_uppe! 
Medtf: 
“edtf: inception" 
"flysforairline" 
"Flysfo: "2019-10-15", 
"flysforevent": "arrival", 
“flysfo:flight_number": "1925", 
"flysforgate": "5BB", 

"flysfo: journey": "LAX-SFO", 
"flysfo: termina 2 
"flysfostimestamp’ 
"geom:area": 0, 
"geom:bbox": "-122.370943,33.942593,-118.38951, 37. 


"2019-10-15", 
"2019-10-15", 

















2, 
: 1571180400, 


61799" 





"geom: latitud 
“geom: Longitude" 
"icaotaircrat 
"icaotairline" 





5.780292, 
120, 380226, 











"sfomuseum:aircraft_id" 
"sfomuseum:airline_id" 
"sfomuseum:arrival_ic 
“sfomuseum:departure_id": 102533795, 
"sfomuseum: flight_id": "20191015-A-ASA-1925", 
“sfomuseum: flight_number": [ 

™AS1925", 

"ASA1925" 


1159292085, 
159283813, 
02527513, 

















"Flight", 





"swim-route", 
“swim-path" , 
"swim-approach" 
1, 
“swim:tail_numbe 
"wor: belongst 
1477855609, 
1477855623, 
102527513, 
85688637, 
102191575, 
85633793, 
85922583, 
102087579, 
1477855605, 
1477855607, 
554784711, 
102085387 





3 "NB36VA", 





The Who's On First browser also supports the display of "alternate" geometries 
which is where we store various flight path data. These include the actual recorded 
path versus the flight plan, the approach or takeoff from SFO and so on. These 
alternative geometries are listed under the src: geom_alt property. 


For example if you visited http: //localhost: 8080/id/1495160039- 
alt-swim-path/ in your web browser you'd see the recorded flight path for 
flight AS1925: 


Who's On First Browser Lookup a Who's On First ID Q 


Point Reyes. 


Death Voiey| 
Notional Pork 


& 
Las Vegas 





1495160039 alt geometry (swim-path) 1495160039-alt-swim-path 


This is an alternate geometry for Who's On First ID 1495160039. 


Its bounding box is 33.91999999999999, -122.33333333333333, 35.75999999999999, 
-118 .44638888888889 


Its principal centroid is 35.75999999999999, -120.38986111111112 


If you visited http: //localhost:8080/id/1495160039-alt-swim- 
approach/ you'd see the detailed path the flight took on its approach in to SFO: 


Who's On First Browser Lookup a Who's On First ID Q 
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1495160039 alt geometry (swim-approach) 1495160039-alt-swim-approach 





Leafiet | Tangram | © OpenStrestMap contributors | Nextzen 


This is an alternate geometry for Who's On First ID 1495160039. 
Its bounding box is 36.72278, -122.3888, 37.17363, -121.88129 


Its principal centroid is 37.17363, -122.135045. 


SFO Museum has contributed enough time and code to the Who's On First Browser 
project to ensure that alternate geometries are supported. When and whether we 
will be able to add search functionality is uncertain. It's definitely something we 
would find helpful so it might happen sooner than later. In the meantime it's a good 
and useful tool for proving that the open data we 


publish https://github.com/sfomuseum-data/ is usable and useful ina 
variety of different tools. 














airmail envelope: Aeroflot Soviet Airlines, Paper, ink. Gift of the Captain John B. Russell Family, SFO Museum Collection, 2012.149.1736 


In the first blog post about collecting flight 
data https://millsfield.sfomuseum.org/blog/2019/01/18/flights/ Inoted 
that: 


Importantly, these data are not being accessioned in to the collection 
yet. There is not a corresponding accession number for each flight on 
every day. It is reasonable to ask: Does it really make sense to collect 
every single flight? Even if it does, is this data better suited for a library 
or an archive, rather than the museum? Conveniently, SFO Museum is 
all three of these things so we’re well-positioned to craft an answer but 
they remain valid questions. 


We still haven't answered the larger question of whether we should accession flight 
data. The notion of rolling up a year's worth of data in to a SQLite database 
suggests how we might accession this and other similar kinds of data, though. 


Rather than adding a few thousand records to our collection management system 
each day perhaps we might add a single record every year and reference a database 
file as the collection "asset". In this way the database is sort of like a traditional 
library finding aid but with built-in searching and indexing. 


Part of the challenge around collecting any digital asset is how to preserve 

it https://mw2014.museumsandtheweb.com/paper/collecting-the-present- 
digital-code-and-collections/ .One of the nice things about relational 
databases is that they are just rows and tables and can easily be exported as comma- 
separated value (CSV) text files. Those files can, if necessary, be printed to paper 
which might seem counter-intuitive but paper is a proven and trusted archival 
material. In this way our flight data starts to look a lot like the log books of the 
past https://www.museumsandtheweb.com/mw2011/papers/bringing_citizen_s 


cientists_and_historians_tog 


Taking the idea one step further we could print these text files using an optical 
character recognition (OCR) friendly 

font https://en.wikipedia.org/wiki/ocR-A and then re-scan those same 
paper files using OCR software https://github.com/tesseract-ocr finally 
re-importing the CSV data back in to a SQLite database. That would be the best of 
both worlds for both preserving and making accessible these kinds of datasets. 
Actually designing and implementing the tools for this sort of archival "round-trip" 
is still just an idea right now so if you, or someone you know, builds it before we do 


please let us know! https: //twitter.com/sfomuseum/ 





photograph: TWA (Trans World Airlines), Boeing 707 final flight, Photograph. Gift of George Gayuski , SFO Museum Collection, 2001.082.108 
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Nh hig jj 
eet LESS < 


LLL W/Z 
Ed NR KES 
SK EDI 
‘ WK rr 
SSS ULL 
7] 


_ Bp WN 
Uy mann 


TTT 


LL“ 
BSSAUIKKKKK 
—= 


= 





I like triptychs https://en.wikipedia.org/wiki/Triptych 


So I made some. 
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Which really means I made some things and cut them in three. 


Because I like triptychs. 
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things | have written about 
elsewhere #20200203 


"Zoomable" images at SFO Museum 


"Zoomable" images at SFO 
Museum 





“Installation view of "Japan Airlines: Over Fifty-Five Years of Service"” 


Image by SFO Museum. It was taken on Apr 1, 2010. 





“Installation view of "Japan Airlines: Over Fifty-Five Years of Service"” 


Image by SFO Museum. It was taken on Apr 1, 2010 


This was originally published on the SFO Museum Mills Field 


weblog https://millsfield.sfomuseum.org/blog/2020/02/03/ 


zoomable/ ,in February 2020. 


We've been talking a lot about image 

processing https://millsfield.sfomuseum.org/blog/tags/iii 
f since this weblog first started. That's because from the very 
beginning of the Mills Field 

website https://millsfield.sfomuseum.org/ the goal has 
been to have tiled and "zoomable" images for every picture and 


every photograph we show on the site. 


Starting today that is the case! There are a few images that still 
need to be tiled but almost every other image can made "zoomable" 
now. In the future we'll do another more technical blog post about 
how the image tiling works but today's post is about celebrating the 
ability to "wander around" an image, to get up close and enjoy its 
details. 





You'll need to have JavaScript enabled in your web browser to see 
zoomable images. If you do and the image has been "zoom-ified" 
thena show zoomable image button will appear underneath 
the image. When you click the button the regular static image is 


replaced with a tiled and zoomable version. 


I've included a live demo with this blog post using the photograph 
above of a handsome brown 

pelican https://millsfield.sfomuseum.org/images/115934246 
5/ from the I Love You California: A Natural 

History https://millsfield.sfomuseum.org/exhibitions/1159 


160585/ exhibition. You should see something like this: 





show zoomable image 


If you don't seea Show zoomable image button you might not 
have JavaScript enabled or there was a problem fetching the 
information about the image tiles. If you don't then the default 
behaviour is to show you the static image like we always have. No 


matter what, handsome pelican is 
handsome https://millsfield.sfomuseum.org/images/115934 
2465/ .If you do see the button go ahead a click it and spend 


some time admiring handsome pelican's details! 





show static image 


“Installation view of "The Allure of Art Nouveau:1890-1914"” 


Image by SFO Museum. It was taken on Feb 17, 2016. 


Zoomable images are often so detailed that you can read label the 
label text for individual objects! 








“Installation view of "Lace: A Sumptuous History (1600s-1900s)"” 


Image by SFO Museum. It was taken on Feb 10, 2014. 





“Installation view of "Lace: A Sumptuous History (1600s-1900s)"” 


Image by SFO Museum. It was taken on Feb 10, 2014. 








Ihave stacks and stacks of screenshots of zoomed-in images and 
this blog post started with most of them. I've trimmed it down to 


just a few of my favourites that I've included here. 





show static image 


“Installation view of "The Mysterious Talking Board: Ouija and Beyond"” 


Image by SFO Museum. It was taken on Oct 25, 2016, 





“Installation view of "The Mysterious Talking Board: Ouija and Beyond"” 


Image by SFO Museum. It was taken on Oct 25, 2016. 


As with the recent updates to the Mills Field historical 
maps https://millsfield.sfomuseum.org/blog/2020/01/10/ma 


p/ zoomable images can be put in to fullscreen mode and you can 


screenshot individual details, using the handy ©: and © controls 


respectively. 


show static image 


“Installation view of "Aviation Evolutions: The Jim Lund 1:72 Scale Model 
Airplane Collection"” 


Image by SFO Museum. It was taken on Oct 2, 2017. 





We have also made "zoomable" images for all the Flickr 

photos https://millsfield.sfomuseum.org/blog/2019/01/02/ 
surface/ of the airports and aircraft the SFO Museum collection 
holds hands with. 


“Korean Air A380 First Class 81” 


This photo was taken by Flickr user Daniel Gillaspia. |t was taken on Feb 16, 2018 and was published under the Creative Commons Attribution- 
NonCommercial-NoDerivs license. It is not part of the SFO Museum collection, 





show zoomable image 


“Air France A380-800 Landing - Plane Watching at In-N-Out Burger near LAX (Los 
Angeles International Airport) - Tuesday June 21, 2016” 


This photo was taken by Flickr user cseeman. It was taken on Jun 21, 2016 and was published under the Creative Commons Attribution- 
NonCommercial-ShareAlike license. It is not part of the SFO Museum collection. 


show static image 





“Air France A380-800 Landing - Plane Watching at In-N-Out Burger near LAX (Los 
Angeles International Airport) - Tuesday June 21, 2016” 


This photo was taken by Flickr user cseeman. It was taken on Jun 21, 2016 and was published under the Creative Commons Attribution- 
NonCommercial-ShareAlike license. It is not part of the SFO Museum collection. 


The best place to get started browsing zoomable images is to click 
the "random" 


button https://millsfield.sfomuseum.org/random at the top 


of every page. It looks like this and will load a random 
exhibition installation image almost all of which have been tiled 
and are ready for exploring. 





show static image 


“Installation view of "Fashion in Flight: A History of Airline Uniform Design"” 


Image by SFO Museum. It was taken on Aug 11, 2017. 


This is the first release of zoomable images so we expect to find 
things that need improving, glitches even, along the way. The 
ability and the infrastructure to assume zoomable images for 
everything going forward is pretty exciting, though. To wrap up 
here is a teaser image for some related work that we are hoping to 
announce in the coming weeks. 





Negative. Transfer, SFO Museum Collection. 2011.032.0496. 





Negative. Transfer, SFO Museum Collection. 2011.032.1530. 
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view cones 


36 Hours In... 


36 Hours In... 


° 


Upper West Side 


City https://spelunker.whosonfirst.org/id/85977539/ 
Angeles https://spelunker.whosonfirst.org/id/85923517/ 
I spent barely more than 36 hours in any one city. These are some 


drawings that I made during those visits. 


Phoenix https://spelunker.whosonfirst.org/id/85917479/ 
and Los 
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always be scrolling 


Cut outs 


Cut outs 


WES SNE “ANAS : 
DMT CEN 
SAIS 37 Vy 







( 
Wy Y TAS Yj, 
RSH HAGE NIN 
SS USS NES ee 
iS SGA W \2 eS 


ee y) iz Nl 
E HW Wy, = iS 











fe TR N \ SS) Ni {\ \ 

Zee sith NTWN\\ AKA 
“a | y i oy WN 
Nt 


Se 






=F SSVxvs 
A? ——. 
VE =a\\h 


es ASST \ })] N iN y | x (\\ \ \\} 
FEIN 


I made some drawings. Then I cut them in to pieces. Finally I glued 


them back together. 
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I'm still not sure whether or not I like this drawing. Shortly after I 
took this photograph it was splashed with drops of water so I guess 


it doesn't matter what I think about it, anymore. 





I definitely have mixed feelings about this drawing. I will keep it 
around for a while longer to see how I feel about it beyond the 
moment, so to speak. 
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things | have written about 
elsewhere #20200320 


Past flight data at SFO and SFO Museum (2006 -... 


Past flight data at SFO and 
SFO Museum (2006 - 2018) 





annual report: San Francisco International Airport (SFO), 1990 [1 issue: 1990], Paper, ink. Transfer, SFO Museum 
Collection, 2001.057.001 .001-.003 


This was originally published on the SFO Museum Mills Field 
weblog https://millsfield.sfomuseum.org/blog/2020/03/20/ 


old-flightdata/ ,in March 2020. 


Today we're happy to announce the availability of historical flight 
data in and out of SFO for the years 2006 through 


2018 https://github.com/sfomuseum-data?q=sfomuseum-data- 


flights-  . That brings the total number of flights published to just 
under 4.9 million! These data are available as raw GeoJSON files 
via the sfomuseum-data https://github.com/sfomuseum-data? 


q=sfomuseum-data-flights- GitHub organization: 


e https://github.com/sfomuseum-data?q=sfomuseum- 
data-flights-  nttps://github.com/sfomuseum-data? 


q=sfomuseum-data-flights- 


We're also in the process of producing per-year SQLite distributions 
for these flight data, as we did for 

2019 https://millsfield.sfomuseum.org/blog/2020/01/24/f1 
ightdata/_ , and will update this blog post with links when they 


are complete. 


Pre-2019 data is sourced from the records of the aiport's Noise 
Abatement department https://www.flysfo.com/noise with 
the following differences from more recent flight 

data https://millsfield.sfomuseum.org/blog/2020/01/24/£1 


ightdata/ 


e Coordinate and elevation data for a flight's takeoff or 
approach are not currently included. We have that 
data and will make it available soon. It involves some 
additional processing and we decided that it was 
worth publishing the data as-is, with pointers and 
coordinate data for arrival and departure 


airports https://millsfield.sfomuseum.org/blog/ 


tags/airports _, first. 


We don't know the tail numbers for any of these 
flights but we do know the 

airline https://millsfield.sfomuseum.org/blog/t 
ags/airlines and aircraft 

model https://millsfield.sfomuseum.org/blog/t 
ags/airplanes for every flight from 2006 to 2018. 
For example, there have been 139,000 Boeing 747- 
400 

flights nttps://millsfield.sfomuseum.org/aircra 
£t/1159289915/flights/ in and out of SFO since 
2006! 


Code-sharing information between airlines is 


unknown. 


Gate information is unknown, but we have ensured 
that each flight is associated with the SFO Terminal 
Complex as it 

existed https://millsfield.sfomuseum.org/blog/t 


ags/architecture atthe time of arrival. 


Some of the sftomuseum: flight_id property 
values will change to better reflect a flight's departure 
date. The reasons why are discussed below. 





negative: San Francisco International Airport (SFO), architectural diagram, Negative. Transfer, SFO Museum 
Collection. 2011.032.1972 


The sfomuseum: flight_id property is a unique identifier that 
we use to key flights from external data sources with flights that 
have been recorded and published as sfomuseum-data-flights- 
YYYY-MM_ https://github.com/sfomuseum-data? 


q=sfomuseum-data-flights- records. It is a compound identifier 
consisting of the departure date, a flag indicating whether the flight 
is arriving at or departing from SFO, the three-letter 

ICAO https://en.wikipedia.org/wiki/Airline_codes#ICAO a 


irline designator airline code and the flight number. 


For example the key 20100127-A-CPA-872 identifies Cathay 
Pacific https://millsfield.sfomuseum.org/airlines/1159284 
127/ flight 872 which arrived at SFO, departing Hong Kong on 
January 27, 2010. The flight 

itself https://millsfield.sfomuseum.org/id/1578260049 
landed at SFO at 12:53 which means it would have left Hong Kong 
around nine or ten o'clock in the morning that "same day". That's 
the funny part about flying back to California from Asia. As the 
clock 

flies https://en.wikipedia.org/wiki/As the crow flies it 
only seems to take a couple of hours despite being in the air for 


twelve, or more, hours. 


NINETEEN HUNDRED AWD SEVENTY TWO —SEVENTY THREE 





annual report: San Francisco International Airport (SFO), 1972/1973 [1 issue: 1972/1973], Paper, ink. Transfer, 
SFO Museum Collection, 2007.048 .014 


The problem is that because of distance and timezones we know 
that some flights arriving at SFO will have departed the previous 
day. The Noise Abatement data only has dates and times for arrivals 
at or departures from SFO. They don't have data for flights 
departing another airport on their way to SFO. In the absence of 
that data every sftomuseum: flight_id property for flights 
arriving at SFO was derived using the date the airplane operating 
that flight touched down in San Francisco. 


It should be possible to calculate an approximate departure date and 
time using a combination of average air speed, great circle 
distance https://en.wikipedia.org/wiki/Great- 


circle distance between airports and timezone 


information https://spelunker.whosonfirst.org/placetypes/ 
timezone/ . There are enough variables in this scenario that there 
would probably still be some mistakes, namely an inaccurate 
departure date, but it would also still be closer to reality than what 
we've got now. At the same time it would require just enough work 
that, like the coordinate data for takeoffs and approaches, it seems 
more valuable to get the bulk and the broad stokes of the data 
published now and to revisit these details later. If anyone else 
would like to take up the challenge before we do we would 
welcome your contributions and pull 

requests https://github.com/sfomuseum-data/ |! 


SAN FRANCISCO'S 
PUBLIC UTILITIES 
COMMISSION 
1953-1954 





annual report: San Francisco Public Utilities Commission, 1953/1954 [1 issue: 1953/1954], Paper, ink. Transfer 
from City and County of San Francisco, SFO Museum Collection, 1999281 .003 


Is it a little surreal to be publishing and writing about historical 
flight data at a time when airplane travel is contracting, and in many 
places grinding to a halt, in order to stem the spread of the Covid- 


19 virus? It's definitely something for sure but it also seems 
important to remember that these data help tell the story of the 
airport. Just as the impact of contemporary travel bans and airlines 
cutting back on routes will be visible in the flight data for 

2020 https://github.com/sfomuseum-data?q=sfomuseum-data- 
flights-2020- what else might we understand about the history 


of SFO, and of commercial aviation, in earlier data? 


Importantly, maybe we won't (or can't) see those stories today but 
that doesn't mean that someone else won't see something in the 
future. We are preemptively betting that the future will see the 


proverbial forest where the present, perhaps, can only see the trees. 


"The phrase “designing for patience” is meant to 
reflect the reality that cultural heritage institutions no 
longer enjoy a monopoly on the general public’s 
attention. This shift away from the academy towards 
large commercial enterprises as well as the 
proliferation of smaller niche publishers, all 
developing and promoting ever more cultural 
production, has been underway for decades. In recent 
years, and particularly with introduction of the 
internet and low-cost mobile computing, the shift has 
picked up speed often being likened to a “firehose” 
in both its intensity and, increasingly, the inability to 


meaningfully make any sense of it. 


"I believe that the broader mission of the cultural 
heritage sector, and the humanities generally, dictates 
that we should not be competing with the immediacy 


of the firehose. Instead we should use digital 


technologies to develop the infrastructure to ensure 
that our collections and our holdings are available 
and accessible and relevant long after the firehose 
has passed. To be confident enough to believe that 
people will revisit an idea, to be patient enough to 
wait for them and to be sustainable enough to make 


both a reality." 


Cope, Aaron. "Capacity Planning for Meaning." 
MW20: MW 2020. Published February 21, 2020. 
Consulted March 19, 2020. 
https://mw20.museweb.net/paper/capacity- 
planning-for- 

meaning/ https: //mw20.museweb.net/paper/cap 


acity-planning-for-meaning/ 


With that in mind, we'd also like to take this opportunity to 
announce that we are collecting and publishing the output of the 
Federal Aviation Agency's https://www.faa.gov (FAA) 
Airport Status API https: //github.com/Federal-Aviation- 
Administration/asws . We've actually been collecting these data 
since August, 2018 and recently made them public through the 
sfomuseum-data https://github.com/sfomuseum-data? 
q=sfomuseum-data-faa- GitHub organization. The status API is 
polled every 15 minutes and archived if and when its output is 
different from the last recorded result. As I write this, there are 


nearly 15,000 status reports spanning two and a half years. 


sfomuseum-data-flights-2020-03 r 
Flight data for arrivals and departures at SFO (March, 2020) 
@Pythn Yo w1 @®o [JO Updated 8 minutes ago 


sfomuseum-data-faa-2020 i’ 
2020 data from the FAA's Airport Status Web Service for SFO. 


Yo wo @o fo Updated’ hour ago 


sfomuseum-data-flights-2014 
Flight data for arrivals and departures at SFO (2014) 


Yo wo @o fo Updated 17 days ago 


Like flight data these records are modeled as Who's On First 
documents https://millsfield.sfomuseum.org/blog/tags/who 
sonfirst and FAA specific data is stored in properties with an 
faa: prefix. Forexample https://github.com/sfomuseum- 
data/sfomuseum-data-faa- 


2020/blob/master/data/152/878/771/3/1528787713.geojson 


{ 

"id": 1528787713, 

"type": "Feature", 

"properties": { 
"edtf£:cessation": "2020-02-21T16:22:54", 
"“edtf:inception": "2020-02-21T16:22:54", 
“faa:credit": "http://weather.gov/", 
"faa:delay": false, 
"“faa:delay_ count": 0, 
"“faa:last_update": "Last Updated on Feb 21 2020, 3:56 pm PST", 
"faa:temperature_c": 19.4, 
"“faa:temperature_f": 67, 


"faa:temperature_raw": "67.0 F (19.4 C)", 
"faa:visibility": 10, 
"“faa:wind_direction": "North", 
"faa:wind_raw": "North at 0.0", 


"faa:wind_speed": 0, 

"geom:area": 0, 

"geom:bbox": "0.000000,0.000000,0.000000,0.000000", 
"geom: latitude": 37.62, 

"geom: longitude": -122.37, 

"mz:is_ current": 0, 


"sfomuseum:placetype": "weather", 
"sfomuseum:uri": "SFO/2020/02/21/20200221T162254.json", 
"sre:geom": "flysfo", 
"wof:belongsto": [ 

102527513, 

102191575, 

85633793, 

102087579, 

85922583, 

102085387, 

554784711, 

85688637 
l, 
"“wof:concordances": { 


"iata:code": "SFO", 
"icao:code": "KSFO" 
}, 
"“wof:country": "US", 


"wof:created": 1582302174, 
"“wof:geomhash": "6e11b039d229c1f441f£d06b875619d83", 
"“wof:hierarchy": [ 


{ 
"campus_id": 102527513, 
"continent_id": 102191575, 
"country _id": 85633793, 
"county_id": 102087579, 
"locality_id": 85922583, 
"postalcode_id": 554784711, 
"region_id": 85688637 

ian 

{ 
"campus_id": 102527513, 
"continent_id": 102191575, 
"country _id": 85633793, 
"county_id": 102085387, 
"region_id": 85688637 

} 


1, 
"“wof:id": 1528787713, 
"“wof:lastmodified": 1582330976, 


"“wof:name": "FAA status for SFO, 2020-02-21T16:22:54", 
"wof:parent_id": 102527513, 

"wof:placetype": "custom", 

"wof:repo": "sfomuseum-data-faa-2020", 


"wof:superseded_by": [], 
"wof:supersedes": [] 


}, 
"bbox": null, 


"geometry": {"coordinates":[-122.37,37.62],"type":"Point"} 
} 


As mentioned the data is available, and updated throughout the day, 
via the sfomuseum-data https://github.com/sfomuseum-data? 
q=sfomuseum-data-faa- GitHub organization. There aren't 
currently plans to publish these data as SQLite distributions but if 


there is a need or a desire we can revisit that decision. 


https://github.com/sfomuseum-data? q=sfomuseum-data-faa- 


We look forward to seeing the tales that might be fashioned from 
the stories these data tell. 


AIR F 


A WORLD-WIDE MARKETAIR SEAVICE 


CargoJet« 
Wide Body 
Schedules 





timetable: TWA (Trans World Airlines), cargo, Paper, ink. Gift of the William Hough Collection, SFO Museum 
Collection, 2004.106.143 
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things | have written about elsewhere 
#20200325 


Airplanes and Walruses — The permanent... 


Airplanes and Walruses — The 
permanent collection of the SFO 
Aviation Museum and Library 





photograph: San Francisco Bay Area aerial, San Francisco and Bay, Photograph. Gift of Charles Page, SFO Museum Collection. 2010.174.315 


This was originally published on the SFO Museum Mills Field 
weblog https://millsfield.sfomuseum.org/blog/2020/03/25/collection/ ,in 
March 2020. 


A healthy slice of the permanent collection of the SFO Aviation Museum and Library is 
now available for browsing on the Mills Field website. This includes a little more than 
23,000 object records of which 18,000 have images. This is still only a small part of the 
museum's total holdings and we hope to get all, or most, of the remaining objects 
online shortly. Like all the images on the Mills Field website, every image from the 
permanent collection is 


"zoomable" https://millsfield.sfomuseum.org/blog/2020/02/03/zoomable/ 





te 
zfs 
ab 


photograph: San Francisco Airport, composite aerial view, Photograph. Transfer, SFO Museum Collection. 1997.52.084.014. Fun fact: We've also 
geo-rectified this object and you can see it, along with other historical aerial maps, on the Mills Field Map page. 


For people who've been following on with this weblog you may have noticed that until 
now most of the work on the Mills Field 

website https://millsfield.sfomuseum.org/ has focused on almost everything 
except the actual collection itself. We've done a lot of work around modeling SFO and 
its architecture https: //millsfield.sfomuseum.org/blog/tags/architecture 
over time, modeling 

airports https://millsfield.sfomuseum.org/blog/tags/airports , 

airlines https://millsfield.sfomuseum.org/blog/tags/airlines and 

aircraft https://millsfield.sfomuseum.org/blog/tags/airplanes/_, thinking 
about maps https://millsfield.sfomuseum.org/blog/tags/maps and about 
flight data https://millsfield.sfomuseum.org/blog/tags/flightdata and 
building out our image 

processing https://millsfield.sfomuseum.org/blog/tags/iiif pipeline. We've 
spent a lot of time on the subject of 

place https://millsfield.sfomuseum.org/blog/tags/whosonfirst , generally. 





photograph: San Francisco International Airport (SFO), International Terminal construction, Photograph. Gift of Edith Lauterbach, SFO Museum 
Collection. 2006.028.176.005 


The reason is because these are all the things that every object in the collection 
intersects with. They are the support cast to the objects themselves that act as the 
boundaries that give the collection its shape. They are the things that people may 
already know and recognize which become entry points in to the collection for those 
who aren't familiar with it or are unsure how to start exploring it. Each is an avenue to 
objects in the collection and, in turn, every object becomes a jumping off point to other 
parts of the collection. 





photograph: San Francisco Airport, Administration Building, Silver gelatin print. Transfer, SFO Museum Collection. 1997.52.078.017 


Did you know that the SFO Aviation Museum and 
Library https://www.sfomuseum.org/aviation-museum-library , shown below, is 


a reproduction of the airport's 1930s passenger lobby, shown above? 





Installation view of the "Mills Field Memories: SFO at 80" exhibition (2007-2008) 


We did not necessarily need to focus on the things that orbit the collection, in advance 
of the collection itself, first but in doing so we have ensured that they don't get 


forgotten along the way. Focusing on these things ensures that the collection has a nest 
of relations and connections in to which it can land (airport puns, notwithstanding). It 
has also allowed us to work through the underlying 

thinking https://www.aaronland.info/weblog/2019/04/08/post/#mw19 and the 
infrastructure details https: //mw19.mwconf.org/paper/mapping-space-time-and- 
the-collection-at-sfo-museum/ governing the Mills Field website, testing those 
ideas and assumptions with a number of small, indepedent, but very much related, 


pieces adjusting to circumstances and gotchas along the way. 


SAN FRANCISCO INTERNATIONAL AIRPORT 
EXPANSION PROGRAM CONSTRUCTION SCHEDULE 
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photograph: San Francisco International Airport (SFO), expansion program and construction, Photograph. Transfer, SFO Museum Collection. 
1997.52.084.095 















NORTH TERMINAL COMPLEX 

EAST TERMINAL COMPLEX 

SOUTH TERMINAL COMPLEX 
TERMINAL SUPPORT FACILITIES 
GROUND TRANSPORTATION COMPLEX 


GROUND TRANSPORTATION COMPLEX 
SUPPORT FACILITIES 


AIRSIDE AREA 
LANDSIDE FACILITIES 


AIRPORT SERVICE FACILITIES 





Some of this work was hinted at in last year's blog post Surface Areas — Photos and 
Depictions on the Mills Field 
Website https://millsfield.sfomuseum.org/blog/2019/01/02/surface/ .In that 


blog post, I wrote: 


Installation view of "Pacific Coast League: The 
i i igue 1903: oh 





Depictions are the things in the 
photographs themselves. For example, 
this photo /images/1159342807/ 

of the Pacific Coast League: The West 
Coast’s Major League 1903- 

1957 /exhibitions/1159160019/ 
exhibition is also a picture of the 
gallery /galleries/1360516195/ , 
the 





This image depicts 


San Francisco International Airport (an aipor) anc G-04 International 
North Wall (a gatery) and SFO Terminal Complex (a busing) anc 

Coast League: The West 
) 





International Terminal (at 
Coast's Major League 1903-1957 








terminal /terminals/1159396147/ , the 
building /buildings/1159396337/ andthe 


airport /airports/102527513/ itself where the exhibition was mounted. 


Which is the next step for the collection: Adding depictions, and relationships, for all 
the objects to all the other things in the collection they hold hands with. For example, 
we've already updated the pointers for objects in the collection associated with airlines 
like Pacific Southwest 

Airlines https://millsfield.sfomuseum.org/airlines/PSA/ 


> mills field Q search SFOMuseun 3% s&s 





show zoomable image 








Photograph. Gift of Carolyn Myers, SFO Museum Collection. 2010.114.018. 


Color photograph of female flight attendant posing with hands raised against exterior fuselage of parked 
PSA (Pacific Southwest Airlines) aircraft; front of aircraft painted with smile livery design.. 


This is object is classified as "Photograph (Print, Photograph)’, and is part of the Aviation Archive 
collection. 


This object depicts 


Pacific Southwest Airlines (PSA) (an airline) 


And Air Canada https://millsfield.sfomuseum.org/airlines/ACA/objects/ : 


Here are three random images of Air Canada 


There are 147 images of this airline / or just jump to random image 


® 


AIR CANADA 





airsickness bag: Air Canada 


And aircraft, like the Airbus 


A320 https://millsfield.sfomuseum.org/aircraft/1159289409/objects/ (and 


Airbus https://millsfield.sfomuseum.org/companies/1159293829/objects the 
company): 








> mills field Q search SFOMuseumn ¥%Y is 
Plastic, paint. Transfer from City and County of San Francisco, SFO Museum Collection. 
2009.036.005 a b. 
a. Air Canada, Airbus A320 desktop model aircraft; white fuselage with red “Air Canada” and maple 
leaf logo printed in red lettering on both sides; silver wings and vertical stabilizers; dark blue vertical 
stabilizer with image of red maple leaf; scale 1:200. b. Clear stand with “Air Canada” and red maple 
leaf logo printed on front.. 
This is object is classified as "Model Aircraft (Model Airplane)", and is part of the Aviation Museum 
collection. 
This object depicts 
Air Canada (an airline) and Airbus A320 (an aircraft) and Airbus (a company) 








And of course, airports like 


SFO https://millsfield.sfomuseum.org/airports/SFO/objects/ 


Here are three random images of San Francisco International Airport 


There are 7,249 images of this airport / or just jump to random image 





negative: San Francisco International United terminal, SFO Airport, San Installation view of "Moto Bellissima: 
Airport (SFO), Concorde Francisco, California #mural #mcleodfun Halian Motorcycles from the 1950s and 
#meleodsonthego #nofilter 1960s" 


This photo is titled “United terminal, SFO 

Airport, San Francisco, California #mural 

#mcleodiun #mcleadsonthego #nofiter” 

and was taken by Flickr user Scott 

McLeod. It was taken on Apr 1, 2017 and 

was published under the Creative 

Cornmons Attribution ficense. It's not part Image by SFO Museum, It was taken on 
of the SFO Museum collection. Nov 23, 2011 


It took a few minutes of refreshing the page for SFO but eventually I managed to pull up three random images where one is from the collection 
(1974), one is a photo from Flickr (2017) and one is an installation shot of a past exhibition (2011). 


We've also made these associations for 

JFK https://millsfield.sfomuseum.org/airports/102534365/objects the 
airport, the Boeing 

747 https://millsfield.sfomuseum.org/aircraft/1159289873/objects/ and 
707 https://millsfield.sfomuseum.org/aircraft/1159289653/objects/ aircraft 
and by extension 

Boeing https://millsfield.sfomuseum.org/companies/1159293593/objects/ 

the company, Qantas 

Airways https://millsfield.sfomuseum.org/airlines/1159285043/objects , 
the Super Bay 

Hangar https://millsfield.sfomuseum.org/buildings/1477855969/objects at 
SFO, the Sikorsky- 

61 https://millsfield.sfomuseum.org/aircraft/1159291711/objects 

helicopter which was used by San Francisco Helicopter 

Airlines https://millsfield.sfomuseum.org/airlines/1159285141/objects to 
shuttle passengers from SFO to the heliport in downtown San 

Francisco https://millsfield.sfomuseum.org/search/? 
q=heliport%20AND$20San%20AND$20Francisco&placetype=object as well as San 


Francisco https://millsfield.sfomuseum.org/cities/85922583/objects itself. 


The goal is to associate unambiguous identifiers with objects in the collection to make 
it faster to find and group specific items (all the objects involving a particular aircraft) 


and to make it easier to perform complex queries across facets (all the objects 


involving that aircraft but belonging to a specific airline and of a certain medium). 


We want to automate this process as much as possible so we're doing this slowly, to 
begin, in order to determine how best to automate the process with the fewest robot- 


generated mistakes. 





negative: San Francisco International Airport (SFO), conference on airport bond issue, Negative. Transfer, SFO Museum Collection. 011.032.1547 


It's important to remember that museums, and museum cataloging, have been around 
for a lot longer than computers and databases. Some of these problems may sound 
straightforward, or even uninteresting, to people who live and breathe modern 
computing systems. The reality for museums is that the metadata I've been talking 
about has never been recorded in a structured model outside of narrative text. It was 
written down and structured in a way to allowed museums to operate in a time before 


computers. 


SFO Museum began life in 1980 so it has always been closer to the world of computers 


and databases than some other museums. It enjoys a mix of unambiguous pointers, and 
structured data as well as narrative language to describe an object's properties. SFO 
Museum is fortunate because it established strict conventions and good practices for 
consistently identifying things in those texts. There are inevitable variations, and the 
occasional unfortunate spelling mistakes, but for many things, we can simply map a 
known string to a stable identifier and look for that string in an object's title or 


description. 


For example, mapping "Pacific Southwest Airlines (PSA) " to airline ID 
1159284973 https://millsfield.sfomuseum.org/airlines/1159284973/ 


> python ./depicts.py 

MATCH 1511923085 timetable: Pacific Southwest Airlines (PSA) 

MATCH 1511924223 photograph: San Francisco International Airport (SFO), Pacific Southwest Airlines (PSi 
MATCH 1511928103 timetable: Pacific Southwest Airlines (PSA) 

MATCH 1511928105 timetable: Pacific Southwest Airlines (PSA) 

MATCH 1511924849 children's in-flight activity kit: Pacific Southwest Airlines (PSA), PSA in Flight Fu 
MATCH 1511924237 photograph: San Francisco International Airport (SFO), airfield 

MATCH 1511929463 ticket jacket: Pacific Southwest Airlines (PSA) 

MATCH 1511929415 baggage destination tag: Pacific Southwest Airlines (PSA) 

MATCH 1511926231 slide: Pacific Southwest Airlines (PSA), Douglas DC-9 Super 80, San Francisco Internat 


This is not a fool-proof solution. We try to match airports in title and descriptions by 
search for its three-letter IATA 

code https://en.wikipedia.org/wiki/IATA_airport_code wrapped in 
parentheses. Unfortunately we've discovered that sometimes those same three letters 
might also be an airline's three-letter ICAO 


designator https://en.wikipedia.org/wiki/ICAO airline designator 


For example, does (SAL) represent El Salvador International Airport 

(SAL) https://millsfield.sfomuseum.org/airports/102556081/ or South 
African Airways 

(SAL) https://millsfield.sfomuseum.org/airlines/1159285187/ ? Stable and 


unambiguous identifiers, right? 


Here are three random images of El Salvador International Airport 


There are 5 Images of this airport / or just jump to random Image 


SIAL] 


SOUTH AFRICAN AIRWAYS SUID-AFRIKAANSE LUGDIENS 


Tydtatel 





timetable: South African Airways (SAL) timetable: South African Airways (SAL) timetable: South African Airways (SAL) 


Does the phrase "Black and white photographic negative 
depicting ground-level airside view of San Francisco 
International Airport (SFO) Heliport" really depict "San Francisco 
International Airport 


(SFO) https://millsfield.sfomuseum.org/airports/102527513/objects "? 





show zoomable image 


negative: SFO Helicopter Airlines, downtown San Francisco heliport 


Negative. Transfer, SFO Museum Collection. 2011.032.2075. 


From attached handwritten note: “03308 / 4-8-69 / Heliport Sign & Bldg. / taken by: Moxom”. Black 
and white photographic negative depicting ground-level airside view of San Francisco International 
Airport (SFO) Heliport; Embarcadero Freeway and tall buildings visible in background; photograph 
taken by Marshall Moxom on April 8, 1969.. 


This is object is classified as "Photograph (Negative)’, and is part of the Aviation Archive 
collection. 


This object depicts 


San Francisco International Airport (an airport) and California (a region) and United 
States (a country) and SFO Helicopter Airlines (an airline) 


As you can see in the images above, we found out the hard way! Both problems have 
since been fixed but this is why we want to be able to assign stable and permanent 
identifiers for the relationships between things in the collection. We want to have an 
unambiguous way to refer to things that are independent of any particula/r textual 


representation. 


It is tempting to think we can acheive better results using natural language processing 
(NLP), machine-learning or some combination of both. It's unclear to me, though, 
whether we could realistically do so, in any acceptable timeframe. 


> go run omd/sfom-collection-prose/main.go phrase ‘negative: San Francisco International Airport (SFO), Jorgen W. Jorgensen’ 
negative 3 


220 

San NNP B-PERSON 

Francisco NNP B-PERSON 
International NNP 8-ORGANIZATION 
Airport NNP B-GPE 

Co 

SFO NNP O 

10 

fret) 

Jorgen NNP B-PERSON 

WNP O 

oo Ml 

Jorgensen NNP 8-PERSON 

San Francisco International Airport PERSON 


Jorgen W PERSON 
negative: San Francisco International Airport (SFO), Jorgen W. Jorgensen 


I did some quick, preliminary tests with a handful of NLP toolkits and at least one of 
them thought SFO is a person. The question of whether or not SFO is a person would 
defintely be an interesting dinner-time conversation but for now let's agree that it's not. 
Ultimately, all the tools displayed similar or equivalent quirks parsing the metadata in 
our collection suggesting that I would spent as much, or more, time correcting for 
errors as I would trying to match fixed labels or patterns in text. Importantly, whatever 
the number of mistakes that either approach yields nothing about the NLP or machine- 


learning approaches suggests that it would result in more correct answers. 


——————— SS 


cisco Chamber of Commerce Salutes 
irportis2o years old 





negative: San Francisco Airport, 25th anniversary celebration, Negative. Transfer, SFO Museum Collection. 2011.032.0285 


It may be that our work, today, is to bridge past museum practice with the present so 
that it might become the training set(s) to power the NLP and machine-learning 
software of the future. The work, today, is to build lots of tools that follow the maxim 
of "good enough is 


perfect https://en.wikipedia.org/wiki/Perfect_is the enemy of good " for 
teasing out the relationships between things in our collection and to develop the 


processes for quickly spotting and fixing errors when they occur. 


This photo is associated with Los Angeles International Airport. 





This photo is titled “Air China Boeing 777-300ER departs LAX" and was taken by 
Flickr user beltz6. 


Make this image public } Delete this image 


Led 





Boeing 777 

Boeing 777-100 
Boeing 777-200 
Boeing 777 Prototype 
Boeing 777-200ER 
Boeing 777-300ER 











This list of aircraft is derived from the sfomuseum-data-aircraft GitHub repository. The plan is to have similar lists for airlines, airports and all the 
different places in the world that our collection objects are associated with. 


Here's an old screenshot of an earlier iteration of some of these tools to add depictions 
to Flickr 


photos https://millsfield.sfomuseum.org/blog/2019/01/02/surface/ .The 
next phase of the work around the collection will be to build new interfaces and 


improve exsiting ones for making these associations, targeted first at staff and gradually 
opening them up to friends of the Museum. 





negative: Mills Field Municipal Airport of San Francisco, Hangar No. 2 construction, Nitrate negative. Transfer, SFO Museum Collection. 
2011 .032.0066 


As with everything else, the metadata for the collection, the classifications used to sort 
and gather collection objects and the images of collection objects are published as open 
data through the sfomuseum-data https://github.com/sfomuseum-data GitHub 


organization: 


e https://github.com/sfomuseum-data/sfomuseum-data- 
collection https://github.com/sfomuseum-data/sfomuseum-data- 


collection 


e https://github.com/sfomuseum-data/sfomuseum-data-collection- 
classifications https://github.com/sfomuseum-data/sfomuseum-data- 


collection-classifications 


e https://github.com/sfomuseum-data/sfomuseum-data-media- 
collection https://github.com/sfomuseum-data/sfomuseum-data- 


media-collection 


There's a lot more to write about the collection but we'll save that for future blog posts. 
You can start exploring the collection by browsing the categories and 
subcategories https://millsfield.sfomuseum.org/collection/ it has been 


organized in to or by seeing where the random 


button https://millsfield.sfomuseum.org/random takes you now that it includes 


objects from the collection. 


> mills field Q search SFO Museum > s&s 


Collections 


This collection of objects has been organized in to the following categories: 





This collection of objects has been organized in to the following categories: 





In closing, I'll leave you with my new favourite 


object https://millsfield.sfomuseum.org/objects/1511908311/ from the 


collection: 





tabletop airplane with walrus, Polished cast aluminum, wood. Purchase, SFO Museum Collection. 1997.80.01 ab 
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Capacity Planning for Meaning 
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airsickness bag: Air Canada. Paper, ink, metal. The Henry Steiner Air Sickness Bag Collection, SFO Museum 
Collection. 2006.026.003 . 


These are the slides for my presentation as part of the Build or 
buy? A debate and discussion of capacity-building for digital 
teams https://mw20.museweb.net/session/papers-10- 
failing-forward/ session at the MuseWeb 2020 conference. 
The talk accompanies the paper I wrote for the conference, 
Capacity Planning for 

Meaning https://mw20.museweb.net/paper/capacity- 
planning-for-meaning/ _, which I've included in full 

below #capacity .I was presenting alongside Chad 

Curtis https://rampantprint.com from the Saint Louis Art 
Museum https://www.slam.org/ and whose paper How to 
Build, When to Buy: Scalable Tactics for Digital Projects and 
Services https://mw20.museweb.net/paper/how-to-build- 
when-to-buy-scalable-tactics-—for-digital-projects-—and- 


services/_ is also included in the conference proceedings. 


The talk itself was meant to be summary and did not try to capture 
all of the nuance and complexities of the subject that the paper tries 
to address. It was meant to recap the thrust of the paper in a way 
that would, hopefully, encourage the audience to push back or 
challenge some of the things I was saying in order foster the 
conversation. Bruce Wyman _ https://museumops.org/bruce- 
wyman/ deserves a big sloppy thank you for chairing the session 


and helping to facilitate the discussion. 


What follows is a reconstruction of my hand-written notes and the 
thrust of what I said during the presentation. These aren't my exact 


words as spoken but they are what I was trying to say. 





@thisisaaronland 
@sfomuseum 
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Hi, my name is Aaron. I am the Head of Internet Typing at the San 
Francisco International Airport 

Museum https://sfomuseum.org/ .The museum and the 
airport are owned and operated by the City and County of San 
Francisco which means that, officially, I have a dull and ambiguous 
title befitting the civil service but "Head of Internet Typing" is the 
best way to describe what I 

do https://www.aaronland.info/weblog/2019/04/08/post/#mw 


19 so it's what I tell people. 


The museum is fully accredited https: //www.aam- 
us.org/2019/11/11/alliance-announces-latest- 
accreditation-awards-17-museums-receive-this-high- 
honor/ and has been operating since 1980. At the moment it has 


25 galleries https://millsfield.sfomuseum.org/galleries/ 


located throughout the airport and has produced more than 1,400 
exhibitions https://millsfield.sfomuseum.org/exhibitions 

/ over the course of the last 40 years. It also has a permanent 
collection of 130,000 

objects https://millsfield.sfomuseum.org/blog/2020/03/25/ 
collection/ focusing on the airport itself as well as commercial 


aviation more generally. 


This talk is not about SFO Musuem, though. It is only about SFO 
Museum in so much as we are a museum and face some of the 
same challenges I want to discuss today. This is a talk about the 


cultural heritage sector as a whole. 
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a circular argument 
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I want to start by suggesting that the sector is stuck in a circular 
argument when it comes to digital technologies and what they make 
possible for our institutions and our collections. Not what's possible 
in a "What if we won the lottery?" kind of way but more about how 
we get anything done given the realities and the constraints we 


operate in today. 


The purpose of this talk is not to point fingers at any one institution 
or to assign blame for past mistakes but to try and make some 
observations, as bluntly and directly as possible, with the hope that 
they might short-circuit the inertia of the current discussion. My 
hope is to jumpstart the conversation about the role and the purpose 
of digital technologies in cultural heritage organizations in new and 


more productive directions. 
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what is "the" digital? 
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One reason I think the conversation is stuck is that we throw around 
the phrases "digital media" and "digital technologies" and even "the 
digital" as general-purpose conversational shortcuts when in fact 
we have very different, sometimes radically different, 


understandings of we mean and expect from the same words. 


For example, when someone talks about "digital" are they simply 
talking about the transition from analog to digital tools as a means 
of production? Are they talking about advances in, and the 
increasing affordability of, computating and storage capacity? Are 
they talking about a global "always on" network of information 
resources? Are they talking about a global participatory community 
of humans and machines alike? 


When I say "digital" I am talking about all of these things. My 


definition should be understood to be more expansive than not, but 
that's just my definition. The same may not be true for another 


person. 
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what is it for? 


for a clean feeling 
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In same vein we are equally unclear about what all of these digital 
technologies are for. 


Is the primary purpose of digital technologies in an institution to 
serve as an attractor, to get people in to the door? Is it meant to 
increase dwell time, to keep people in the building longer than they 
might otherwise stay? Is it to make that instituton, or its collection, 
look and feel more like the contemporary culture that most visitors 
are already familiar with? 


Is the purpose to be a 

MacGuffin https://en.wikipedia.org/wiki/Macguffin by 
which we might address larger issues in an institution or the sector? 
Already, one person at this conference has spoken about digital 
technologies as a way to challenge the primacy of the (museum) 


object in favour of the community and the larger public. 


I believe the reason we should invest in, embrace and deploy digital 
technologies is because they are a transformational mass on 
institutions and their collections. The application of these 
technologies allows them to make a conceptual leap, similar to the 
one made by educators, that distinguish them from their curatorial 
counterpart. That is it, they act as another lens on to the institution 
and its practice, not better or worse, but recognizably different and 


valuable on their own terms. 


Again, my definition should be understood to be more expansive 
than not, but that's just my definition. The same may not be true for 


another person. 
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It is important to step back for a moment and point out that my 
purpose here is not to convince you to adopt my definition of digital 
technologies. There are many equally valid definitions and the 


circumstances that led to them. 


My purpose is, though, to suggest that when we use the same short- 
hand to talk about very different things we may have difficulty 
trying to achieve what we think are common goals or in agreeing 


on how to accomplish them. 


I think that disconnect is at the heart of why the conversations we 
have about making the possibilities afforded by digital technologies 
a tangible and sustainable reality are so difficult. We are talking 
about different things. Again, those differences are legitimate but 


we owe it to each other, and to ourselves, to be able to clearly 


articulate what we mean when we say "digital". 


as a museum visitor 
| am looking for a 
big reveal experience 
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Traditionally, digital initiatives have followed the model used to 
produce exhibitions. Often digital initiatives are compliments to, 
and in service of, those exhibitions. They have a high production 
value, involving significant amounts of labour and budgetary 
resources. They have known boundaries and are, out of necessity, 
relatively inflexible to change because once launched they, like the 
exhibitions they serve, are meant to run unattended for the time it 


takes an institution to produce the next exhibition. 


There is nothing inherently bad about this model. I just think it 


represents a lost opportunity. 











This litter bag is for your convenience. You may 
take it with you if you desire. It can also be used 
for airsickness should the occasion arise. 





revisiting an idea 


BRANIFF INTERNATIONAL 
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The reason I think it's a lost opportunity is two-fold. 


First, when I look at digital technologies, and remember my 
definition is expansive and includes things like the internet, I see 
the tangible means by which an institution can extend itself beyond 
both an atomic visit and the building a person is visiting. In the 
paper that accompanies this talk I write that cultural heritage 


institution should embrace digital technologies because: 


e They provide the tangible ability to produce a 
multiplicity of avenues, where they did not exist before, 
into an institution’s collection and the history of its 


curatorial practice. 


e They allow those same avenues to extend beyond the 


physical footprint of an institution, to reach a global 
audience and to do so asynchronously. They allow 
these avenues to stay open, or “always on,” such that 
people can find them at a time and a place of their own 


choosing. 


e They afford the freedom, both intellectually and 
importantly financially, to limit the costs, risks and 


consequences involved in these efforts. 


These are things that we have not able to do in the past and they are 
the things that enable our institutions to be taken for granted in the 
same way that people have come to take services like Google and 
Wikipedia for granted. These are services that in their ubiquity 
people have made an extension of their lived experience. It should 
come as no surprise to people in the cultural heritage community 
that these services, and others like it, are where people turn to find 
out about our collections but we should endeavour to fulfill that 


role. 


I don't believe we can accomplish this without building and 
maintaining a digital scaffolding around our institutions and our 
collections which ensures and promotes a revisiting of these things, 
independent of any given visit, at a time and place of an individual's 


choosing and rationale. 


The second part of my argument centers around my belief that the 
bedrock of the humanities is the practice of revisiting an idea. To 
revisit, reconsider and to reimagine a subject are at the core of 


cultural heritage. Without them, and without the ability to practice 


them, what is to separate our work and our collections from any 
other commercial enterprise or broadcast-based entertainment 


channel? 
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I mention these things because they are important but become 
crucially important when it comes times to decide how we pay for 
these projects, how we maintain them and who does the actual 
work to build them. By and large the cultural heritage has out- 
sourced the technical implementations, and the support, of our 
digital initiatives to third-party vendors the same way we might 
contract a fabricator to build furniture for a gallery. This is still very 
much the norm as evidenced by the majority of nominees and 
winners of this year's GLAMi 

Awards https://www.museweb.net/best-of-the-web/ 


working in collaboration with outside agencies. 


I'm going to keep saying this: There's nothing inherently wrong 
with this approach. 


If past work is any guide, though, it shows us that it is an approach 
which yields projects that are slow and expensive to produce, 
difficult to update or integrate with other projects and generally 
brittle and ultimately ephemeral. Dependening on how you are 
approaching digital technologies and the reasons for doing so in the 
first place these may not be concerns you need to worry about. The 
cost of a project, and its relative longevity, might be entirely offset 
by the rewards it generates elsewhere. 


In the event of sickness 


for assistance 


do it yourself British Caledonian 
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The point I am trying to make is that while there is, and will always 
be, a role for outside vendors to play in our work there is a whole 
landscape of projects and ambitions for which they are entirely ill- 
suited. Their business models do not permit them to devote the time 
and the resources to a prolonged and iterative process often 
involving significant customization and tailoring to meet the needs 


of any given institution. 


Even if their business models did permit these things it is unlikely 
that an institution could afford the cost. And if an institution could 
afford the cost for that kind of work delivered over months and 
years, essentially a retainer, it begs the question of whether it could 
put that much money to better use. For example, using that money 
to hire full-time staff with a mandate to tackle and solve those same 
problems, to develop long-term institutional capacity that outlasts 


any one team member and that reduces the cost of the inevitable 


failures to something that is manageable rather than catastrophic. 


The point I am trying to make is that these are things that are not 
self-realizing, that someone needs to do the work to actualize them 
and that the people the sector has traditionally relied on are both a 
poor fit for the job and simply too expensive for the scope of the 
work. An institution doesn't have to do these things that I've 
described. As I've said a few times now there are other, equally 
valid approaches to "the digital" in an institution. 


If we are going to try and do them, though, I think it's time, long 
overdue in fact, that we recognize we will have to figure out how to 


do them ourselves. 





outlasting reluctance 
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Part of this work will require thinking about how we develop and 
implement projects in such a way that they outlast reluctance. We 
need to develop the capacity, culturally and technically, to outlast 


the initial reluctance to an idea whether it is internal or external. 


Inevitably some ideas and initiatives will be failures but some of 
them will be new, and challenging, enough that they need more 
time for people to warm up to them. Sometimes it's a question of 
leaving enough time and space for belief in a project to germinate 
and other times it's simply a question of being patient enough to 


wait in the queue, so to speak, of people's busy lives. 


There is a pervasive, and I think ultimately destructive, belief that 
everything we do needs to compete with and be measured in terms 


of the so-called "attention economy". We don't and we shouldn't. 


Just because someone has to pick up their kids on the day you 
launch your new shiny thing doesn't mean they won't eventually 
cycle back to it. It might take them a week, or two weeks or even a 
year but aren't we, the cultural heritage sector, in it for the long 


game? 


designing for patience 
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This revisiting is what digital technologies make possible and we, 
as a sector, need to develop the skill and the practice to make it both 
real and sustainable. This will be a non-trivial amount of work and 
it will be hard and there will be a learning curve, some of it steep, 
to develop the capacity to do these things in a way that is 
conceptually and financially. We need to develop the capacity to 
allow both visitors to revisit projects but also for an institution to 
revisit, reconsider and improve those same projects. Critically we 
need to be able to do these things without them being major 
undertakings. 


It is work that will need to acknowledge and address the mistakes 
that were made around similar past efforts. It is work that will need 
to ultimately overcome but initially be resilient to at least a few 
false starts. 


All of this will be made harder still because it forces a lot of long- 
standing, and complicated, issues around hiring and retention and 


salaries in the cultural heritage sector to rise to the surface. 


That difficulty will be exacerbated by the challenge of competing 
with the benefits afforded by for-profit technology companies and 
competing amongst ourselves for the limited pool of people who 
will sacrifice the rewards of the private sector to help us accomplish 


our work. 


thank you 
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And it's a lot of work. This is why I keep coming back to the need 
to articulate what an institution means when it speaks of "the 


digital" and why it believes it is important. 


Without these things there will be little to convince the staff the 
sector needs to attract to give up the creative comforts of the 
technology world. Without these things there will be little to 
convince the visitors the sector claims to serve that we are not, in 


fact, just another pit stop in the attention economy. 


Thank you. 
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Capacity Planning for 
Meaning 


“Because, there are no futures without histories.” 
(Jain, 2020) 


This paper was originally published on the MuseWeb 2020 
conference https://mw20.museweb.net/paper/capacity- 
planning-for-meaning/ website. 


Designing for patience 


The idea of “designing for patience” is for cultural heritage 
institutions to develop capacity to make their digital infrastructure 
resilient to uncertainty whether that is unstable funding or reluctant 
audiences or both. That capacity needs to be seen as an on-going 
and long-term investment, developed and maintained internally, 
spanning, and in service to, the history of an institution rather than 


any single exhibition or project. 


The phrase “designing for patience” is meant to reflect the reality 
that cultural heritage institutions no longer enjoy a monopoly on the 
general public’s attention. This shift away from the academy 
towards large commercial enterprises as well as the proliferation of 
smaller niche publishers, all developing and promoting ever more 
cultural production, has been underway for decades. In recent 
years, and particularly with introduction of the internet and low- 
cost mobile computing, the shift has picked up speed often being 
likened to a “firehose” in both its intensity and, increasingly, the 


inability to meaningfully make any sense of it. 


I believe that the broader mission of the cultural heritage sector, and 
the humanities generally, dictates that we should not be competing 
with the immediacy of the firehose. Instead we should use digital 
technologies to develop the infrastructure to ensure that our 
collections and our holdings are available and accessible and 
relevant long after the firehose has passed. To be confident enough 
to believe that people will revisit an idea, to be patient enough wait 
for them and to be sustainable enough to make both a reality. I do 
not believe it is possible to do these things without developing the 


practice and the capacity to do them internally. 


In order to discuss these ideas further we first need to spend some 
time defining what is meant by the terms “digital” and 
“infrastructure.” The terms “digital,” “digital media,” and “digital 
technologies” are frequently used interchangeably but, just as often, 
absent any consensus about what they mean or represent. When 
someone speaks of digital technologies it is not often clear what 
they mean. The ambiguity of meaning when two or more people 
discuss digital technology is often the root of misunderstandings or 
disagreements about broader topics. 


In the “What is ‘Digital?’” appendix to this paper I have included a 
list of potential meanings that are all equally applicable or relevant 
when discussing “digital media” and “digital technologies.” This is 
not an exhaustive list of what might be considered as “digital”, and 
importantly there are equally valid interpretations that contain only 
a subset of that list. 


For the purposes of this paper the meaning of “digital” should be 


understood to be more expansive than not. When I speak of “digital 


technologies”, I am referring to all of things listed in the appendix, 


whether they are realized or unrealized potentialities. 


Equally, the phrase “infrastructure” can mean different things to 
different audiences in the cultural heritage sector . For the purposes 
of this paper, infrastructure is defined primarily, but not exclusively, 
as software projects grouped in to one of four generalized 


categories. 


e External-facing systems, with commonly understood 
conventions and established boundaries. Typically 
these are built and operated by commercial vendors 


with a mass audience. 


e Internal-facing systems, with broadly understood 
conventions specific to the cultural heritage sector. 
Generally these are built and operated by commercial 


vendors with a focus on the cultural heritage sector. 


e Internal-facing systems, specific to a given institution. 
Increasingly these are built and operated by dedicated 
staff in an institution but this internal capacity is still 
mostly limited to institutions of a certain size and 


operating budget. 


e Public-facing systems, specific to a given institution. 
Historically these have been built and maintained by 
third-party agencies with a focus in exhibition design 
and/or digital applications. In recent years the cultural 


heritage sector has taken responsibility for some of 


these systems but by and large they remain outsourced. 


Detailed examples of each category are included in the “What is 


“Infrastructure?” appendix to this paper. 


Separations of concern 


All of these infrastructure systems, or layers, are used in tandem 
and in concert with one another during the course of normal 
operations in a cultural heritage institution. All are “digital” but that 
does not mean they are the same. Each has unique tolerances and 
affordances and distinct requirements and skill sets to operate and 
maintain. Understanding these separations of concern is critical for 
the cultural heritage sector, particularly when it comes to staffing, 
because each incurs demands that are not necessarily portable from 


one category to another. 


It is important to distinguish these layers in order to answer one 
simple question: What is the function of digital technology inside 


of a cultural heritage institution? 


There is not a single “right answer” to this question. But because 
there are a multiplicity of answers it is important for an institution 
to be able to articulate their position on the question. To be able to 
explain why digital technologies are even part of an institution’s 
mission, independent of which technologies are chosen or how they 
are deployed. Ideally, the “why” should influence the decisions 
about the “what” and the “how.” Regardless, the reasons why an 


institution chooses to entertain digital technologies in the first place 


will dictate whether the “what” and the “how” succeed or fail. 


There is nothing about the dynamics of a “why-what-how” 
relationship that is unique to digital technologies. It exists in most, 
if not all, institutional endeavors. Digital technologies, however, 
have an uncommon ability to force the tensions in the “why-what- 
how” dynamic to the surface because the promise of “what” they 
can achieve is so alluring while the realities of “how” to accomplish 


those things can be unexpectedly complex. 


I take the position that the role of digital technologies should not 
limited to a supporting role, solely as a compliment to an 
institution’s existing practice and mirroring it in digital media. I 
believe that the reason “why” a cultural heritage institution should 
embrace digital technologies, as defined by the list above, is three- 
fold: 


1. They provide the tangible ability to produce a 
multiplicity of avenues, where they did not exist before, 
into an institution’s collection and the history of its 


curatorial practice. 


2. They allow those same avenues to extend beyond the 
physical footprint of an institution, to reach a global 
audience and to do so asynchronously. They allow 
these avenues to stay open, or “always on,” such that 
people can find them at a time and a place of their own 


choosing. 


3. They afford the freedom, both intellectually and 


importantly financially, to limit the costs, risks and 


consequences involved in these efforts. 


Digital technologies as a whole are a vast canvas so this list is only 
one possible framing of their qualities and properties. I have chosen 
these three because they are the qualities and properties that are 
genuinely novel. These are things that we have not able to do in the 


past. 


Units of currency 


The act of revisiting is a touchstone of the humanities. The repeat 
consideration, and often reconsideration, of a body of work is what 
distinguishes the humanities from other endeavors. Without this 
there is little to separate our practice from the cataloging of 
instruction manuals or traffic reports (both of which are collected 


by some institutions). 


In many institutions the “unit of currency” used to define their 
efforts remains the exhibition, rather than the collection or its 
broader mission seen in an historical context. The past, when it is 
made manifest, is only available in the form of a printed exhibition 
catalog. An always-on and connected network means that an 
institution is no longer quantified by the atomic isolation of a 
building, a single exhibition or an exhibition catalog but rather its 
ambient presence and the ease with which its present can be 


connected to its past, not to mention everything else. 


In other words, everything a museum does is connected to 


everything a museum has done not just for those with institutional 
knowledge but for the greater public audience that an institution 


exists to serve. 


Historically, institutions have undertaken linear and sequential 
series of themed exhibitions, often both labor intensive and 
expensive to produce, culminating in big splashy “reveals” 
designed to buoy an institution for the time it takes to complete the 
next set of exhibitions. This model of working, sometimes 
described as “fire and forget,” no longer matches people’s 
expectations. This is one place where digital technologies can be 
crafted as a kind of scaffolding that serves to promote the practice 
of revisiting and to buttress a culture of reflection, alongside 


existing practice. 


The challenge of changing expectations is exacerbated further by a 
series of issues, unrelated to digital technologies, affecting the 


cultural heritage sector as a whole: 


e The language of the humanities and the cultural 
heritage sector is often too far-removed from people's 
day-to-day lives. The humanities has evolved and 
promoted a language of discourse that many people 
simply do not understand or have any means of 


relating to. 


e The cost of participating with or visiting cultural 
heritage institutions more than once, if at all, is often 
prohibitively expensive, seen as exclusionary, or simply 


not worth it because it does not connect with people’s 


lived experience. 


e The assumption on the part of many institutions that a 
substantial portion, if not the majority, of their visitors 
will be tourists and likely to only ever visit once. As a 
consequence little is done to encourage repeat 


visitation, either in the physical space or online. 


At the same time, we are living through a moment in history when 
the over-arching cultural zeitgeist is a sense of helplessness and a 
powerful belief that nothing short of radical transformational 
change will accomplish anything or, worse still, even be noticed. To 
be a cultural heritage institution in the twenty-first century, then, is 
to operate in a noisy and cluttered space referred to as the “attention 
economy” where the very air itself often feels as though it has been 


weaponized. 


Research has shown that museum visitors’ 
encounters with art are generally brief —an average 
viewing time of 28.6 seconds per work, according to 
a 2017 study by Jeffrey and Lisa Smith and Pablo 
Tinio at the Art Institute of Chicago. That time 
includes reading the label and, for “a large 


percentage of visitors” taking selfies, they noted. 


(https://www.museus.gov.br/wp- 
content/uploads/2019/04/The-Art-Newspaper- 
Ranking- 

2018.pdf) https: //www.museus.gov.br/wp- 
content/uploads/2019/04/The-Art-Newspaper- 


Ranking-2018.pdf 


Compounding this reality is a growing belief that there is only a 
single chance for cultural heritage institutions to capture people’s 
attention and a disbelief that any of our efforts can buoy themselves 
longer than an initial first impression. That in order to survive and 
prosper we must produce ever more elaborate spectacles whose 
primary function is to serve as attractors giving us equal, or at least 


improved, footing in an increasingly crowded “attention economy.” 


In this context the function of digital is best described as an 
aspirational signifier. Its manifestation and its reasons for existing 
are measured only by whether or not it successfully captures 
people’s attention in an ocean of distractions. In this context 
anything that does not produce an immediate reaction, or that yields 


any reluctance on the part of its target audience, is understood as a 


failure. 


As the perceived need for spectacle drives ever more elaborate and 
costly productions so too do the stakes increase. The impact of a 
failed production can have significant consequences for an 
organization’s budget and its appetite for, and importantly its belief 


in, future efforts let alone revisiting and improving past work. 


Even when they do succeed institutions are typically left with a 
digital infrastructure consisting of expensive one-offs produced by 
outside vendors that do not age well, almost never interoperate with 
one another and are ill-suited to adaptation. There is never a past to 


work from, only a high-priced future to rebuild from scratch. 


We also have to look at our own interests and 
participation in this system as what I call the donee 
class. Donors give and trustees serve because artists 
and museum staff beg them to do so. This has 
become the primary job of directors of institutions in 
the US. The rising costs of museums, which 
necessitate huge gifts from wealthy donors, are not 
primarily driven by board members. They are driven 
by the ambitious expansion plans of directors, the 
grand visions of starchitects and the skyrocketing 
prices of artists’ work. This growth is driven by 
competition and ambition, not by need. It creates an 
extremely steep pyramid of resource distribution, in 
which a few individuals and institutions at the top 
absorb the vast majority of the total resources in the 
field. The corporate populist museum needs 
spectacle and the whole system flatters donors into 
funding it. (Millar Fisher & Fraser, 2020) 


Outlasting reluctance 


Reluctance, though, is a kind of resistance. It can be understood a 
necessary survival mechanism. It is a not uncommon reaction to 
new ideas, new modes of operating or simply new opportunities. It 
is normal and, in moderation, healthy. The pragmatic act of 
suspending belief (or disbelief) is sometimes necessary for the 
simple reason that people are busy and need to prioritize their 


attention. 


But just because someone does not warm up to an idea immediately 


or on someone else’s schedule does not mean they cannot or will 
not. Not all connections, or relevancies, are made in the moment. 
Nor can they be. As often as not those connections are only made 
after, sometimes long after, a first impression. Just as often if a 
remembered impression has no way to reestablish that connection it 


is lost forever. 


Without the means to reestablish those connections, without recall, 
how can there be a revisiting? Without revisiting is there even a 
cultural heritage to preserve and promote? I argue that being the 
means of not simply establishing connections, but reestablishing 
them, is the the principal function of the cultural heritage sector, by 


whatever means the present makes available. 


To that end the role and function of digital technologies inside a 
cultural heritage sector should be to promote and foster those 
means. To that end we need to develop and architect those 
technologies not with the principal aim of a short-term attention 
economy but instead with the goal of weathering the long-term and 
usually meandering process of creating meaning across as many 


audiences as the technologies allow to reach. 


With legitimate reason, some people may ask: Is this not the role 
that for-profit services like the Google search engine or not-for- 
profit organizations like the Wikimedia Foundation or the Internet 
Archive perform? Google would certainly like to assume the role of 
a memory institution in people’s lives as would many members of 
the Wikimedia community. In many respects they already have. 
Digital technologies have allowed us to see recall as something we 


can, that we should be able to, take for granted. Recall has joined 


the list of things that are only noticed in their absence. 


Many, if not most, people already use services like Google or 
Wikimedia as the primary means of discovery and importantly 
rediscovery for works in our collections. Are we, as a sector, ready 
to cede both the control and the responsibility of being the means of 
discovery for our collections? Are we willing to delegate the 
decision making process around those means to a third-party, 
whether or not they operate as a profit-driven enterprise? If not then 
we need to see these services, and the ways that people are already 
using them, as a guidepost for the kinds of functionality we need to 


build and maintain ourselves going forward. 


In 2019, I wrote (Cope, 2019) that : 


The present offers us the ability to harness the 
databases, the publishing tools, the programming 
languages and networks of communities and 
broadcast channels that have been created, in many 
instances for entirely other purposes, in the service 
of our collections and the mandates that our 
institutions claim. The goals are not new but what is 
new is that many of those goals are actually within 
reach now. That these goals are within reach does 


not, however, mean they are self-realizing. 


If an institution believes the role and function of digital 


technologies is to meet the expectations of the present and to avail 


itself of the possibilities, near and future, that these technologies 
suggest, it also needs to recognize that these things are not “self- 


realizing.” 


Concretely, the sector needs to invest, and in some cases re-invest, 
in dedicated staffing for digital technologies inside cultural heritage 
institutions. That means investing operational, rather than capital, 
funds in long-term dedicated staffing for the institution-specific 
internal-facing and public-facing systems, described in the 
infrastructure list above. Of these two, the most immediate and 
pressing need is to develop in-house capacity around internal- 
facing systems and public-facing online systems and to ensure that 
capacity both spans and outlasts any one project or single 


employee. 


These are the systems that bridge the collections management 
systems and any public-facing endeavor an institution undertakes, 
usually with outside vendors. These are the systems that need to 
enforce structures and methodologies defined by and tailored to the 
long-term vision of the institution rather than the short-term needs 
of an outside vendor. These are the systems that influence 
everything the public sees and so it stands to reason an institution 


should have a stake, an opinion and a hand in how they are built. 


In doing so an institution itself begins to act as the bridge 
connecting the many polyglot projects undertaken over time, both 
internal and external, which would otherwise be short-lived 
eventually perishing in isolation. In doing so an institution begins to 
develop the skills, the understanding and crucially the infrastructure 


to develop and operate its own public-facing systems. To do so not 


at the expense of third-party vendors but in a way that ensures a 


more level, and more cost-effective, playing field of possibilities. 


In doing so an institution learns to understand and conceive of its 
digital infrastructure as something that outlasts any one project and 
fosters confidence in its capacity to produce and sustain long-term 
and open-ended projects. Comfort with the long-term and with 
projects that have no fixed end-date is a prerequisite for patience. 
Patience, in turn, is a prerequisite for developing systems that are 
able to meet the irregular and meandering needs of the humanities 


as a whole. 


The whole point of a digital team inside an institution is to do those 
things. Not only the big reveal but “version two” and then “version 
three” and so on. The purpose of a digital team inside an institution 
is to build and nurture the infrastructure so that each subsequent 
project is easier than the last or at the very least creates new 
challenges rather than retreading the same ground over and over 
again. These are precisely the sorts of things that outside agencies 
are not set up to do. It is not their business and no amount of 
wishful, or magical, thinking on the part of their clients (the cultural 


heritage sector) will make it so. 


“Infrastructure” here should be understood to mean both the 
technological and cultural scaffolding that supports an institution. 
Another crucially important function of an in-house team is to be 
able to respond and adapt to mistaken assumptions along the way. 
To reduce “the cost of failure”, real or imagined, from being seen as 


catastrophic to being understood as addressable. (Cope, 2019) 


Put bluntly, none of the opportunities and potentialities offered by 
digital technologies described in this paper are possible without 


dedicated staff. The opportunities are not “self-realizing.” 


There has always been, and remains, a role for outside vendors and 
for outsourcing parts of an institution’s infrastructure. The mistake 
that is too often made, though, is to assume those vendors are the 
correct solution for all of that infrastructure equally. If an institution 
wants to explore and leverage digital technologies as a core 
component of their mission then dedicated staffing is the only 
means by which these goals can be met and, crucially, be made 
sustainable and affordable. Given a desire to make digital 
technologies integral to an institution then absent dedicated staff 
there seems little point in discussing what is or is not possible 


outside the offerings in a vendor’s promotional material. 


To make possible what was previously 
impossible 


The question of staffing and retention in the cultural heritage sector 
is long-standing and complex, bordering on existential. It quickly 
points to larger structural problems about how museums are funded 
and how that funding gets allocated. It highlights the equally 
complicated problems about how the non-profit sector competes 


with the salaries and compensation offered by the private sector. 


This is especially true when the question is staffing for digital 
technologies but, in 2020, digital staff is only expensive relative to 


other functions at a museum. When you look at the kinds of salaries 


the private sector will bear for that same digital staff it only serves 
to highlight the unfair salaries the cultural heritage sector promotes 
in the first place. These salaries help fuel the on-going problem of 
retention in the sector which makes building and sustaining long- 
term team-based efforts, digital or otherwise, even harder than they 
are to begin with. When you consider the sum totals of money that 
are spent on outside contractors and especially outside technology 
contractors in the cultural heritage sector it remains something of a 
mystery how it is that we cannot both raise salaries across the board 


and sustain in-house digital teams. 


To make these ideas concrete consider the following list, all blog 
posts, or papers, taken from the Cooper Hewitt’s Digital and 
Emerging Media “Labs” website 

(https://labs.cooperhewitt.org/ https://labs.cooperhewitt.or 


g/ ): 


e Making “Dive into Color” (Vane, 2018) 


e Process Lab: Citizen Designer Digital Interactive, 
Design Case Study (Adang & Nackman, 2016) 


e Traveling our technology to the U.K. (Walter, 2016) 


e Museums and the Web Conference Recap: 
Administrative Tools at Cooper Hewitt and Winning 
(and losing) hearts and minds of museum staff: 
Administrative interfaces at Cooper Hewitt (Adang & 
Brenner, 2016) 


e On Exhibitions and Iteration (Brenner, 2016) 


e Iterating the “Post-Visit Experience” (Brenner, 2015) 


e “Visual Consistency” - tweaking the online collection 
(Brenner & Ghraowi, 2015) 


e Happy Staff = Happy Visitors: Improving Back-of- 
House Interfaces (Shelley, 2015) 


e Redesigning Post-Purchase Touchpoints (Shelley, 
2015) 


The “digital” team at Cooper Hewitt has never been more than five 
people at any given point in time. Five people is neither small nor 
big in a museum context but it is illustrative of what the 
contemporary technology landscape makes possible. The work 
above was done in-house and on staff-time, all while maintaining 
museum operations and the existing digital infrastructure that was 
launched to support the Pen as part of the museum’s re-opening in 
2014. All of this work was built on, extended and informed by the 
work done for the re-opening. It was done for a fraction of the time 
and cost that a third-party vendor would have charged to do the 


same. 


I worked at Cooper Hewitt from 2012-2015 and was involved with 
the museum’s re-opening and the launch of the Pen (O’Kane, 
2015). One aspect of that work which has not been addressed as 
much was the awareness and understanding that in order for the 


work to be considered a success it had survive the departure of the 


original team. Success meant ensuring a degree of continuity in 
staffing that would allow the larger project to survive being 
“handed off” from one team to the next, or the loss of any one team 


member. 


Ultimately, the value of building and nurturing and sustaining core 
capacity in-house can be understood as: Making possible what was 
impossible, or so impractical as to seem impossible, before. In- 
house teams do not necessarily make that work easy, but they 


should make it possible. 


This is the work 


As a sector we have spent a couple of decades making excuses for 
why “digital” cannot be made core to staffing requirements and the 


results have ranged from unsatisfying to dismal. 


The shift to a “post-digital” museum where “digital [is] being 
naturalized within museums’ visions and articulations of 
themselves” (Parry, 2013) will require a significant realignment of 
priorities and an investment in people. The museum sector is not 
alone in this — private media organizations and tech companies face 
exactly the same challenge. Despite “digital people” and engineers 
being in high demand, they should not be considered an 
“overpriced indulgence” but rather than as an integral part of the 
already multidisciplinary teams required to run a museum, or any 


other cultural institution. 


The flow of digital talent from private companies to new types of 


public service organizations such as the Government Digital 
Service (UK), 18F (inside GSA) and US Digital Service, proves 
that there are ways, beyond salaries, to attract and retain the 
specialist staff required to build the types of products and services 
required to transform museums. In fact, we argue that museums 
(and other cultural institutions) offer significant intrinsic benefits 
and social capital that are natural talent attractors that other types of 
non-profits and public sector agencies lack. The barriers to 
changing the museum workforce in this way are not primarily 
financial but internal, structural and kept in place by a strong 
institutional inertia. (Chan & Cope, 2015) 


In 2020 the question of how to fund, staff and sustain digital teams 
inside the cultural heritage sector remains largely unanswered. It is 
made more complicated by similar work undertaken during the 
previous decade. Have past teams dedicated to technology and “the 
digital” inside of museums over the last decade, having been given 
a wide berth and substantial budgets, lived up to their promise? I 
think it is pretty clear that when you average out all the efforts of 
the last ten years, including the successes, the answer is no. That is 
not something most people want to hear but it is important to be 
clear-eyed and honest when we reflect on past work in order to see 
where all the good intentions failed in the face of operational 


realities. 


A lot of money and resources were allocated towards those efforts. 
Many failed or were simply abandoned, leaving in their wake both 
suspicion and ill-will on the part of donors or others in their 
respective institutions. This is reality we occupy in 2020 and 


acknowledging and addressing those concerns and grievances can 


not be optional. Nor should it be. This is our burden and this is the 
work. That mistakes were made, though, is not reason enough to 


give up on the project of building in-house digital capacity. 


Arguably in a world where the expectation for the kinds of services 
and capabilities that digital technologies make possible grows every 
year there is even more urgency to try again. That mistakes were 
made simply means we might better understand what not do going 


forward. 


There are no quick fixes for building and nurturing that capacity. It 
will be a multi-year effort first to establish, or re-establish, 
credibility for the idea, then to argue for changes in the funding 
models and then to attract staff. Once those staff are in place it will 
take time for them to understand the needs and history of the 
institution, its staff and whatever projects preceded them. How and 
where a digital team sits in the organization chart may need to be 
reevaluated. Learning how to correctly identify roles and to scale 
digital teams in order to work effectively and to ensure succession 
plans will require trial and effort. It will require a diligence and 
focus on the part of that staff that was not always present in past 
efforts. 


Larger institutions, with commensurate budgets and staff can play 
an important role by actively hiring and training junior-level staff 
with the expectation, encouragement even, that they might leave 
and take on more senior roles at smaller institutions. If the greater 
goal is one of building self-sufficiency and sustainability across the 
sector then, at least in short-term, we need to think about the project 


as larger than any single institution. 


Critical to the challenge of staffing and retention will be an 
institution’s ability to articulate why they are entertaining digital 
technologies at all. In order for an institution to attract the staff it 
needs and wants those reasons why need to be the “intrinsic 
benefits and social capital” by which a person will choose the 
cultural heritage sector over the private sector and for those factors 
to have a higher motivational value than the salaries offered by the 


private sector. 


I find it useful to think about approaching digital technologies in 
cultural heritage institutions as being akin to a perennial flower 
garden: In the beginning things are pretty sparse and nothing is very 
big. Sometimes empty space are filled in with short-living annuals 
flowers, bright and colorful in the moment but destined to fade 
away quickly. Most things are expected to survive the winter but it 
is understood that others do not. Sometimes plants are moved 
around and some plants do not flower every year. Although this 
might sound like a recipe for nothing ever getting done, no one, I 
think, would accuse a dedicated gardener of lacking design or 
effort. 


I suggest that a successful gardener depends on patience and a 
tolerance for the unknown and even failure in equal measure. The 
biggest and most beautiful gardens, not unlike cultural heritage 
institutions, are complex living systems spanning years and even 
lifetimes. Digital technologies are often mistaken for fully-formed 
gardens when they are not. They can, however, with care and 
commitment, be made so and my hope is that this paper has 
presented a compelling argument for why that work is worth 


pursuing. 


A transformational mass 


I would like to close with a thought-experiment, perhaps even a 


provocation: 


Digital technologies inside of cultural heritage institutions have the 
potential to serve as a kind of transformation mass, offering 
genuinely unique outlooks and methodologies for approaching and 
understand not just an institution’s collections and holdings but the 
institution. This is sometimes labeled as “the digital humanities” 
but I think that they are closer in spirit and sentiment to an 


institution’s education department. 


Importantly the application of these technologies allows them to 
make a conceptual leap, similar to the one made by educators, that 
distinguish them from their curatorial counterpart. That is it, they 
act as another lens on to the institution and its practice, not better or 


worse, but recognizably different and valuable on their own terms. 


For me, this is the “why” of pursuing digital technologies in the 
cultural heritage sector. It acts as the foundations for figuring out, 
and advocating for, the “how”. After that, the only question left is 
“what” to do next? 

Appendix 

What is “digital?” 


When someone speaks of digital technologies do they mean: 


A medium of production, and the transition from 
analog to digital materials? For example, graphic 


design tools like Adobe Illustrator or Photoshop. 


A broadcast medium reflecting the most widely 
available consumer technology, in the moment? For 


example, live or on-demand video-streaming services. 


Advances in storage and retrieval technologies and 
their increasingly availability and affordability? For 
example, the Amazon Web Services S3 storage service 


or the Elasticsearch document store and search engine. 


Advances in media processing and other 
computational manipulation? For example, remote 
computing platforms like Amazon Web Services, 
Google Cloud Platform or Heroku. 


Advances in computer vision, machine learning and 
algorithmic inference. For example, tools like Intel’s 
OpenCV, Google's TensorFlow, nVidia’s image in- 
filling software. 


Free and open source software. For example, the Linux 
operating system or the Python programming 


language. 


Low cost, open source hardware platforms and the 
abundance of programmable sensors. For example, the 
Raspberry Pi, Arduino, and Feather computing 


platforms, motion and temperature sensors or near- 


field communications technologies like RFID and 
Bluetooth. 


e The internet and more generally the assumption of 
“always on” network connectivity to external 


resources? 


e All of the above bundled as third-party services, often 
referred to as “software as a service” or “cloud” 


providers? 


e A global audience and communities of interest? For 
example, social media services like Facebook or 


Twitter or self-hosted group forums. 


e A distributed and asynchronous framework for 
document persistence and retrieval? For example, the 
World Wide Web. 


e Distributed messaging services, synchronous and 
asynchronous, for both humans and machines alike? 
For example, Twitter, group messaging services and 


other “push” notification systems. 


e All of the above bundled as a participatory 
“experience?” For example, virtual reality, augmented 


reality, or multi-player games. 


For the purposes of this paper “digital media” and “digital 
technologies” refer to all of these things whether they are realized 


or unrealized potentialities. This is not an exhaustive list of what 
may be understood as “digital” and importantly there are equally 


valid interpretations that contain only a subset of the list above. 


What is “infrastructure?” 


Equally, the phrase “infrastructure” can mean different things to 
different audiences in the cultural heritage sector . For the purposes 
of this paper infrastructure is defined primarily, but not exclusively, 
as software projects grouped in to one of four generalized 


categories: 


e External-facing systems, with commonly understood 
conventions and established boundaries. Typically 
these are built and operated by commercial vendors 


with a mass audience. 


e Internal-facing systems, with broadly understood 
conventions specific to the cultural heritage sector. 
Generally these are built and operated by commercial 


vendors with a focus on the cultural heritage sector. 


e Internal-facing systems, specific to a given institution. 
Increasingly these are built and operated by dedicated 
staff in an institution but this internal capacity is still 
mostly limited to institutions of a certain size and 


operating budget. 


e Public-facing systems, specific to a given institution. 


Historically these have been built and maintained by 


third-party agencies with a focus in exhibition design 
and/or digital applications. In recent years the cultural 
heritage sector has taken responsibility for some of 


these systems but by and large they remain outsourced. 


Example of external-facing systems include an organization’s email 
or calendaring service or common document formats, such as text 
processing or spreadsheets. In all cases services and standards are 
defined by third-parties or commercial vendors targeting a 
heterogeneous audience. Typically these services are managed by 
an institution’s information technology (IT) department or, 


increasingly, as a remote service. 


Examples of internal-facing system used sector-wide are 
commercial collections management or inventory tracking systems. 
These are systems that contain a mix of data suitable for public 
release and sensitive or otherwise restricted data used in the course 
of operations. As with email or calendaring services these tools are 
often managed by the IT department or as remote services hosted 


and maintained off-site. 


Examples of institution-specific internal-facing systems might be 
tools for gathering data for an exhibition (Adang & Brenner, 2016) 
or manipulating data in alternative interfaces than those provided 
by commercial collections management system. (Berg-Fulton & 
Newbury & Snyder, 2015) These tools might be developed and 
maintained by an in-house digital team but may also be the 
necessary by-product of public-facing systems produced by 


external vendors. 


Examples of institution-specific and public-facing digital systems 
are in-gallery interactive displays (Alexander & Barton & Goeser, 
2013) or a larger physical-digital envelopes designed to foster 
visitor participation in an exhibition (Chan & Paterson, 2019). 
Historically these have been developed by outside vendors and 
maintained only for the duration of an exhibition. Typically these 
are time and capital expensive projects designed to attract as many 
people as possible to an institution or to attract donors and other 
funding sources for future projects. Public-facing systems also 
include the primary means of accessing information about an 
institution or its holding, usually in the form of one or more 
websites. These may be operated by in-house digital staff, an IT 


department or a third-party vendor. 
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Just before or, depending on how you want to look at things, just as 
everything started going off the rails we were able to spend some 


time in Puerto Rico. These are some of the postcards I made and 


sent to people during that trip. 
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This last one was not a postcard but a sketch I did on the flight back 
to the mainland. The guy in the seat in front of me was wearing an 
N-95 mask and a sleep mask and glaring at his row mate who was 
still talking on the phone as we taxied to the runway. Which sort of 


feels like a scene that's been playing on an endless loop, ever since. 
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Geotagging Photos at SFO Museum, Part 1 -... 


Geotagging Photos at SFO 
Museum, Part 1 — Setting the 
Stage 





negative: San Francisco International Airport (SFO), Annual 
report press conference. Negative. Transfer, SFO Museum 
Collection. 2011.032.2788. 


This was originally published on the SFO Museum Mills Field 
weblog https://millsfield.sfomuseum.org/blog/2020/04/23/ 


geotagging/ ,in April 2020. 


This is the first of a multi-part blog post (11 in all!) about 
geotagging photos in the SFO Museum 

collection https://millsfield.sfomuseum.org/blog/2020/03/2 
5/collection/ . It's also a blog post about how we're doing that 
work and why we're taking a longer road than we might otherwise 
to get there. Over the course of the next couple weeks we'll post 


one short blog post a day focused on a specific step, or area of 


concern, in that process. This first blog post will set the stage and 
outline some of our motivations for seeing geotagging photos in our 


collection as a chance to address larger issues in the cultural 
heritage sector. 
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A few years as part of their Space/Time 
Directory https://spacetime.nypl.org/ project, the New 


York Public Library https://nypl.org/ (NYPL) released the 
Surveyor http://spacetime.nypl.org/surveyor/#/ web 


application, a tool that allows individuals to geotag the photos in 
the NYPL 


collection https://digitalcollections.nypl.org/ 


All of the code for the Space/Time Directory is open 


source software https://github.com/nypl-spacetime 
including the Leaflet.GeotagPhoto https://github.com/nyp1- 
spacetime/Leaflet.GeotagPhoto extension to the 

Leaflet.js https://leafletjs.com/ map library. The extension 


provides a handy interface for not just indicating the location where 
a photo was taken but also its field of view. 


Leaflet.GeotagPhoto 


Leaflet plugin for photo geotagging. 
Examples: 


© Crosshair mode 
¢ Camera mode 


@ OO | | Camera -LeatiereotagPnoto x = 
< © CQ _D httox//spacetime.nyplorg: iet.Geo xample ®@: 
+ Leaflet .GeotagPhoto 
= Mode: Camera (switch to Crosshair) 
+ Leaflet plugin for photo geotagging. See 
© GitHub for details. 
Output: 
e 
2 { 
"type": "Feature", 
"properties": { 
"angle": 51 


“bearing”: -57.30567181215952, 
"distance": 720.2014973115098 





and 
: "GeometryCollection", 
"geometries": [ 
"type": "Point", 
“coordinates”: [ 
~73.99002313613893, 
40.70471701226029 


"type": “LineString", 


<sSeae x "coordinates": [ 
o { 


~73.9994117666073, 
40.7056150330789 
l. 


{ 
-73.99501097423718, 
40.710813423792956 


> : —\ } 
( angle: - - 1° 
ee aS 


Leatet | © OpenStreetMap contibutors, © CARTO 


Leaflet.GeotagPhoto is part of The New York Public Library's NYC Space/Time Directory. 


You can also find Leaflet.GeotagPhoto on Leaflet's plugin page. 


Adding the Leaflet .GeotagPhoto extension to the Mills 
Field https://millsfield.sfomuseum.org and implementing 
controls to limit access to staff would have been pretty easy and 
pretty fast. But geotagging photos (images, really) is something that 
lots of people, and institutions, want to be able to do. This felt like 
an opportunity to develop a standalone and extensible tool that does 
one and only one thing: Geotag images independent of where those 


images come from or where the newly created data goes to. 


The larger motivation for doing things this way is to build on work 
we described in the Using the Placeholder Geocoder at SFO 
Museum https://millsfield.sfomuseum.org/blog/2019/11/04 
/placeholder/ and to attempt to address an evergreen subject in 
the cultural heritage sectotor: The lack of common software tools, 
and the challenges of integrating and maintaining those 


infrastructures, across multiple institutions. 


My own feeling is that many past efforts have failed because they 
tried to do too much. It's a bit of a simplification but a helpful way 
to think about these tools is to imagine they consist of three steps: 


e Data comes from somewhere. For example, an image 
comes out of a database and an asset management 


system. 


e Something happens to that data. For example, an 


image is geotagged. 


e The data then goes somewhere else. For example, the 


geotagging data goes in to a database. 


The problem with many tools, developed by and for the sector, has 
been that they spend a lot of time and effort to abstract the first and 
the last points and ultimately fail. The nuances, details and 
limitations, not to mention the vast inequalities, in all the different 
technical infrastructures within the cultural heritage sector are 
legion. Developing an abstraction layer for the retrieval and 
publishing of cultural heritage materials that attempts to integrate 
and interface directly with an institution's technical scaffolding is 


going to be a challenge at best and a fool's errand at worst. 


A S089 7-28-3/ CENTURY FACIFIC TH 





photograph: San Francisco Airport, Century Pacific Stinson 
SM-6000-B tri-motor NC10840 at Mills Field. Gelatin silver 
print. Collection of SFO Museum, SFO Museum Collection. 


1993.07.17.002 a. 


Recent efforts like the International Image Interoperability 
Framework https://iiif.io/ (IIIF) have made good strides 
to defining a common way to talk about retrieval and publishing 
between disparate systems but, importantly, leave the actual 
implementation details to individual systems. IIIF describes a way 
that systems should speak to each one another but doesn't try to do 
any of the talking itself. 


Rather than automating where the data comes from, or goes to, we 
would be better served as a sector to focus on shared tools that 
automate what can happen to data and making it both easy to ingest 
and export in the process. 


The cultural heritage sector needs as many of these small, focused, 
tools as it can produce. It needs them in the long-term to finally 
reach the goal of a common infrastructure that can be employed 
sector-wide. It needs them in the short-term to develop the skill and 
the practice required to make those tools successful. We need to 
learn how to scope the purpose of and our expectations of any 
single tool so that we can be generous of, and learn from, the 


inevitable missteps and false starts that will occur along the way. 


A good example of this is the way the Leaflet .GeotagPhoto 
extension was designed and released indepedent of the Surveyor 
application itself. While another institution might want to run their 
own instance of Surveyor it's really an application informed by 
and designed for the specific needs of NYPL. But that doesn't 


prevent them from building another application on top of the 
Leaflet .GeotagPhoto plugin. 
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negative: Oakland Airport, runway construction. Nitrate 
negative. Transfer, SFO Museum Collection. 2011.032.0012. 


It is with that spirit in mind that we set out to build a simple and 
extensible stand-alone web application for geotagging images. 
Ultimately, as you'll see in the blog posts to follow, this is an 
application designed by and for SFO Museum but we hope we've 
done things in a way that allows another institution to adapt and 


rearrange its core building blocks to suit their own needs. 


In closing, here are some screenshots of the result of this 

work https://millsfield.sfomuseum.org/objects/1511943935 
/ to date. They show the same field of view for an image of the 
main terminal building under construction, in 1953, ten years 
before and three years after the photo was a taken. 
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show zoomable image 


negative: San Francisco Airport, Terminal Building 
construction 





Negative. Transfer, SFO Museum Collection. 2011.032.0318. 


From attached handwritten note: “04029 / 4-8-53 / New pssgr. term. 
bldg”. Black and white photographic negative depicting construction 
of Terminal Building (later Central Terminal, now Terminal 2 / T2) at 
San Francisco Airport; view facing west toward steel frame of building 
under construction; photograph taken on April 8, 1953.. 


This is object is classified as "Photograph (Negative)", and is part of 
the Aviation Archive collection. 


Leaflet | © OSM contributors | Nextzen | Who's On First | SFO Museum 





As you can see the field of view for this photo is a bit short. It 
should extend all the way to Sweeney Ridge to the West of the 
airport but insteads stop at the Terminal building. We'll cover 
updating and fixing geotagged photos in a later blog post. 
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Geotagging at SFO Museum, part 2 — First Steps 


Geotagging at SFO Museun,, part 2 — 
First Steps 





negative: Pan American World Airways, Pacific-Alaska Division. Negative. Gift of 
William E. Talbott, SFO Museum Collection. 2012.151.156. 


This was originally published on the SFO Museum Mills Field 
weblog https://millsfield.sfomuseum.org/blog/2020/04/24/geotagging-first- 


steps/ ,in April 2020. 


This is the second of an 11-part blog post about geotagging 
photos https://millsfield.sfomuseum.org/blog/tags/geotagging inthe SFO 


Museum collection. At the end of the first 
post https://millsfield.sfomuseum.org/blog/2020/04/23/geotagging/ I said: 


[W]e set out to build a simple and extensible stand-alone web application 
for geotagging images. Ultimately, as you’ ll see in the blog posts to follow, 
this is an application designed by and for SFO Museum but we hope we’ ve 
done things in a way that allows another institution to adapt and rearrange 


its core building blocks to suit their own needs. 


We've chosen the Go programming language https://golang.org for developing 
this application. Go is not necessarily the first or always the best choice for web 


applications so here are the pros and cons that informed our decision: 


e Go has a steeper learning curve than other programming languages. Until 


you get the hang of it Go can seem profoundly weird. 


e Go is a strictly-type language that needs to be compiled to run which 
means that it is often just a little bit slower to do the same thing than it 
might in another language. 


e Writing web applications that need to change quickly and often in Go is 
not very much fun because of the first two points and because Go's built-in 
templating support is not as flexible as others. 


e On the other hand this application is designed to be pretty simple and not 
change a lot. Much of the logic is contained in the application's JavaScript 
layer which can be edited locally and tested quickly in a web browser. 


e Go makes it very easy to write the server-side components of a web 


application and ships with built-in support for creating web servers. 


e Go has robust support for serving web applications locally, in a 


traditional server setting and in the cloud. 


e Go allows you to compile and serve all of your web application's assets 
(HTML templates, Javascript and CSS files and so on) in to and from the 
application itself. 


e Go applications can be pre-compiled in to operating system specific 
binary applications that don't require any additional steps or 


dependencies to run. 





photograph: San Francisco International Airport (SFO), expansion program and 
construction. Photograph. Transfer, SFO Museum Collection. 1997.52.084.109. 


This last point is really important. In the end we may deploy this application for staff as 
a hosted website on the internet but we would like to have the ability and the flexibility 
for staff to also run the application locally, from their desktop, regardless of whether 
they are using Windows or a Mac or even the Linux operating system. The majority of 
museum staff are not developers and won't know how or be able, or want, to install the 
external dependencies that might be necessary for an application written in another 


programming language to run. 


Ultimately, the Go part of our application is little more than a web server wrapped 
around a standard HTML + JavaScript + CSS web application that could be run in any 
number of environments. That's by design so that the "meat" of the application doesn't 


get painted in to a corner of any single programming language or platform. 


There is, in fact, more to the Go part of the application than a web server and we'll 
cover those details in later blog posts. At the same time, if you've ever had to set up 
and maintain a web server by hand then having Go take care of those details and wrap 
everything up in a canned application that runs by itself is a welcome development. So 


that's why we chose Go for this application. 
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timetable: BEA (British European Airways). Paper, ink. Gift of the William Hough 
Collection, SFO Museum Collection. 2005.132.065.004. 


With that in mind, the first thing we did was write what's referred to as a "middleware" 
handler for the Leaflet.GeotagPhoto https: //github.com/nypl- 
spacetime/Leaflet.GeotagPhoto plugin we talked about in the last blog 


post https://millsfield.sfomuseum.org/blog/2020/04/23/geotagging/ 


In his blog post Making and Using HTTP 
Middleware https://www.alexedwards.net/blog/making-and-using- 


middleware Alex Edwards describes middleware this way: 


When you're building a web application there's probably some shared 
functionality that you want to run for many (or even all) HTTP requests. 
You might want to log every request, gzip every response, or check a cache 


before doing some heavy processing. 


One way of organising this shared functionality is to set it up as middleware 
— self-contained code which independently acts on a request before or after 
your normal application handlers. In Go a common place to use middleware 
is between a ServeMux and your application handlers, so that the flow of 
control for a HTTP request looks like: 


ServeMux => Middleware Handler => Application 
Handler 


In Go, "ServeMux https://golang.org/pkg/net/http/#ServeMux "is the name of 
the code that routes requests for a URL to a specific piece of application code, also 
called a "handler". 


Our middleware, which is published in the go-http-leaflet- 

geotag https://github.com/sfomuseum/go-http-leaflet-geotag package, 
bundles all the files and dependencies used by the Leaflet .GeotagPhoto plugin 
and makes them available locally to a web application. It can also be configured to 
intercept requests for webpages and inject all the relevant markup so that an application 


can start to use the Leaflet .GeotagPhoto JavaScript library. 


Here's an abbreviated example of what this looks like in code: 


import ( 
“github.com/sfomuseum/go-http-leaflet-geotag" 
"net/http" 

) 

func main(){ 


mux := http.NewServeMux() 


// Make all Leaflet.GeotagPhoto files available 
geotag.AppendAssetHandlers (mux) 


camera_handler, _ := PageHandler(t, "“camera") 
// Inject markup for using Leaflet.GeotagPhoto files in to a web page 
geotag_opts := geotag.DefaultLeafletGeotagOptions() 


camera_handler = geotag.AppendResourcesHandler(camera_handler, geotag_opts) 


mux.Handle("/camera/", camera_handler) 


Let's imagine the output of the PageHand1ler code above looks like this: 


<html> 
<head> 
<title>PageHandler</title> 
</head> 
<body> 
<p>Hello world</p> 
</body> 
</html> 


After it is processed by the geotag. AppendResourcesHandler middleware 
code it looks like this: 


<html> 

<head> 
<title>PageHandler</title> 
<link rel="stylesheet" type="text/css" href="/css/leaflet.css" /> 
<link rel="stylesheet" type="text/css" href="/css/leaflet.fullscreen.css" /> 
<link rel="stylesheet" type="text/css" href="/css/Leaflet.GeotagPhoto.css" /> 
<link rel="stylesheet" type="text/css" href="/css/highlight.min.css" /> 
<script type="text/javascript" src="/javascript/leaflet.js.js"></script> 
<script type="text/javascript" javascript/leaflet.fullscreen.min.js"></script> 
<script type="text/javascript" src="/javascript/leaflet-hash.js"></script> 
<script type="text/javascript" src="/javascript/Leaflet.GeotagPhoto. js"></script> 
<script type="text/javascript" srce="/javascript/highlight.min.js"></script> 

</head> 

<body> 








<p>Hello world</p> 
</body> 
</html> 


And the geotag. AppendAssetHandlers (mux) method is what adds all those 
/javascript/...and/css/... URLs to the mux (the ServeMux mentioned 
above) so that requests for those files succeed. 


That's it. 


The go-http-leaflet-geotag https: //github.com/sfomuseum/go-http-leaflet- 
geotag middleware layer doesn't define how your application uses the 


Leaflet .GeotagPhoto extension. The point of this middleware layer is to make 
adding the Leaflet .GeotagPhoto extension to your application as easy as three 


extra lines of code. 


Leaflet .GeotagPhoto 


Mode: Camera (switch to Crosshair) 


Output: 


+ 


{ 





"angle: i 
"bearing": -137.6646301182176, 
808.0841567140344 


Ot 


"distance": 


h, 
"geometry": { 
"type": "GeometryCollection" 
® "geometries": [ 
» all ] "type": "Point", 
e "coordinates": [ 
7 4 -122.369499, 
e ' 37.624837 
f 1 
h, 
{ 
"type": "LineString", 
"coordinates": [ 
[ 
-122.37207093822164, 
37.61686505485521 
He 
-122.37928145603509, 
37.62206772010241 


7 
Angle: 56° 
Leaflet | © OpenStreetMap contributors, © CARTO 


The default example application that's included with the go-http-leaflet- 
geotag code base simply recreates the example application in the 


Leaflet .GeotagPhoto code base. 


In the next post we'll use this piece of middleware to start building our geotagging 


application. 
2020-04-24 
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Geotagging at SFO Museum, Part 3 — What Is the... 


Geotagging at SFO Museum, 
Part 3 — What Is the Simplest 
Thing? 








photograph: Spruce Goose. Paper, ink. Gift of Frank A. Norick, SFO 
Museum Collection. 2016.042.022. 


This was originally published on the SFO Museum Mills Field 
weblog https: //millsfield.sfomuseum.org/blog/2020/04/27/geotagg 


ing-simple/ ,in April 2020. 


The is the third of an 11-part blog post about geotagging 

photos https://millsfield.sfomuseum.org/blog/tags/geotagging 

in the SFO Museum collection. At the end of the second 

post https://millsfield.sfomuseum.org/blog/2020/04/24/geotagging 


-first-steps/ I said: 


In the next post we’ll use the go-http-leaflet- 
geotag https://github.com/sfomuseum/go-http- 
leaflet-geotag middleware package to start building our 


geotagging application. 


If you're not sure what the "middleware" refers to please have a look at the 
last blog post nttps://millsfield.sfomuseum.org/blog/2020/04/24/geotagging- 


first-steps/ for a discussion of the term. 


And this is what that application looks like: 












San Francisco, 
International 








ANOR = 
BAYFRC [eatiet | Tangram | © OpenStreetMap contributors | Nextzen 





vy GeoJSON 
{ 
“type": "Feature", 
“properties”: { 
“angle": 66.96857065294023, 
"bearing": 96.63998458311976, 
"distance": 887.0449235773463 
}, 
"geometry": { 
"type": "GeometryCollection", 
"geometries": [ 
{ 
"type": "Point", 
"coordinates": [ 
—122.38100051879884, 
37.618922560587684 
] 
iP 


e 


It looks pretty similar to the screenshot for the example application included 
with the go-http-leaflet-geotag https://github.com/sfomuseum/go- 
http-leaflet-geotag package we talked about in the last 

post https://millsfield.sfomuseum.org/blog/2020/04/24/geotagging 


-first-steps/ 


Leaflet .GeotagPhoto 


Mode: Camera (switch to Crosshair) 


+ 


Output: 


{ 
"type": "Feature", 
“properties”: { 

"angle": 56, 

"bearing": -137.6646301182176, 

"distance": 808.0841567140344 


Or 


hy 
“geometry”: { 
"type": "GeometryCollection", 


® "geometries": [ 

-" { 

~ "type": "Point", 
"coordinates": [ 


La ' 
y -122.369499, 
37.624837 
] 


' 

’ } 
{ : : 

"type": "LineString", 

“coordinates": [ 


-122.37207093822164, 
37.61686505485521 


l, 


-122.37928145603509, 
37.62206772010241 


] 


la 


—— 
( Angle: 56° ) 


Leafiet | © OpenStreetMap contributors, © CARTO 


There are a few layout changes but most of the differences are under the 
hood, and unseen, making use of functionality provided by a number of 


additional "middleware" packages: 


e The go-http-bootstrap nttps://github.com/aaronland/go- 
http-bootstrap package. This bundles 
Bootstrap https://getbootstrap.com/ , a framework for 


developing responsive and mobile websites. 


e The go-http-leaflet nttps://github.com/aaronland/go- 
http-leaflet package. This bundles 


Leafletjs nttps://leafletjs.com/ , a framework for web- 


based mapping applications. 


e The go-http-tangramjs https://github.com/aaronland/go- 


http-tangramjs package. This bundles 


Tangramjs https://github.com/tangrams/tangram ,d 
framework for styling and rendering data in web-based 


mapping applications. It also exports a handful of default 
Tangram map styles https://github.com/tangrams? 


utf8=%E2%9C393&8q=-style which define the cartography and 


visual elements used by Tangram.js to render tile data provided 


by Nextzen https://www.nextzen.org/ ,a free and open 


provider of geographic data for web-based mapping 


applications. 


e The go-http-tilezen https: //github.com/sfomuseum/go- 
http-tilezen package. This can be used to proxy and cache 
local copies of Nextzen https://www.nextzen.org/ tile 


data. 


Here's an abbreviated example of how that fits together in code: 


import ( 
"github.com/aaronland/go-http-bootstrap" 
"github.com/aaronland/go-http-tangramjs" 
"github.com/sfomuseum/go-http-leaflet-geotag" 
tz_http "github.com/sfomuseum/go-http-tilezen/http" 
"github.com/sfomuseum/go-www-geotag/www" 
"net/http" 

) 


func main() { 
mux := http.NewServeMux() 


tiles handler, _ := tz_http.TilezenProxyHandler(...) 
mux.Handle("/tiles", tiles_handler) 


tangramjs.AppendAssetHandlers (mux) 
bootstrap.AppendAssetHandlers (mux) 
geotag.AppendAssetHandlers (mux) 


bootstrap_opts := bootstrap.DefaultBootstrapOptions() 


tangramjs_ opts := tangramjs.DefaultTangramJSOptions() 
tangramjs_opts.Nextzen.APIKey = "your-nextzen-api-key" 
tangramjs_opts.Nextzen.StyleURL = "/tangram/styles/refill.zip" 
tangramjs_opts.Nextzen.TileURL = "/tiles/{z}/{x}/{y}.mvt" 


geotag_ opts := geotag.DefaultLeafletGeotagOptions() 
// this is where most of the logic for the actual 
// geotagging application lives 


editor_handler, _ := www.EditorHandler(...) 


editor_handler 
editor_handler 


bootstrap.AppendResourcesHandler(editor_handler, bootstrap_opts) 
tangramjs.AppendResourcesHandler(editor_handler, tangramjs_opts) 


editor_handler = geotag.AppendResourcesHandler(editor_handler, geotag_opts) 


mux.Handle("/", editor_handler) 


} 


With the exception of the go-http-leaflet-—geotag handler and the 
application-specific code highlighted in blue this is almost exactly the same 
code we used to develop the geocoding application described in the Using 
the Placeholder Geocoder at SFO 

Museum https://millsfield.sfomuseum.org/blog/2019/11/04/place 


holder/ blog post. And that's the point. 


Bootstrap https://en.wikipedia.org/wiki/Bootstrap_(front- 

end framework (started by and for Twitter in 2011), 

Leaflet https://en.wikipedia.org/wiki/Leaflet_(software ) (also 
started in 2011 and used by almost everyone who isn't Google Maps), 
Tangram and Tilezen (started in 2013 and 2015, respectively, as part of the 
Mapzen https://en.wikipedia.org/wiki/Mapzen project) represent 
decades of effort and problem-solving and finessing offered to the world in 
a spirit of generosity. We don't need, or have the time, to reproduce that 


work. 


Being web-based technologies we could also have simply downloaded each 
project locally and bundled them directly in our geotagging application. It's 


a chore, sometimes a nuisance, to have to do that for every project though. 





negative: San Francisco International Airport (SFO), Terminal 
Building construction. Negative. Transfer, SFO Museum Collection. 
2011 .032.0339. 


The weight and impact of these go-http- middleware packages, each of 
which SFO Museum https://github.com/sfomuseum has developed 
internally or actively contributed to, shouldn't be overstated. They are "tools 
of convenience" designed to make integrating external functionality in a 


bespoke application quick and easy. 


They are simple tools but they are part of our attempt to make good on 
something I said in the first blog 
post https://millsfield.sfomuseum.org/blog/2020/04/23/geotagging 


/ in this series: 


The cultural heritage sector needs as many of these small, 
focused, tools as it can produce. It needs them in the long-term 
to finally reach the goal of a common infrastructure that can be 
employed sector-wide. It needs them in the short-term to 
develop the skill and the practice required to make those tools 
successful. We need to learn how to scope the purpose of and 
our expectations of any single tool so that we can be generous 
of, and learn from, the inevitable missteps and false starts that 


will occur along the way. 


As of this writing our geotagging application is published in an 
unimaginatively named package called go-www-geotag a 
href="https://github.com/sfomuseum/go-www-geotag .A better name 


is probably in order but this one will do for the time being. 


We don't yet provide pre-compiled binary versions of the application so in 
order to fetch and build the application you'll need to have a tool, like wget 
or simply your web browser, to download the source code and the Go 
programming language https://golang.org/dl for building it: 


# As I write this the releases for the go-www-geotag package change often 
# so the best thing is to vist https://github.com/sfomuseum/go-www-geotag/releases 
# and download the most recent release. 


$> wget https://github.com/sfomuseum/go-www-geotag/archive/v{X}.{Y}.{Z}.zip 
$> unzip v{X}.{Y}.{Z}.zip 


$> cd go-www-geotag 
$> go build -mod vendor -o bin/server cmd/server/main.go 


To start the application you would type: 


$> ./bin/server \ 
-nextzen-apikey {NEXTZEN_API_KEY} 


2020/04/15 08:56:56 Listening on http://localhost:8080 


In order to use the application you'll need to sign up for a Nextzen API 
key https://developers.nextzen.org/ and pass that key in with the - 


next zen-apikey flag. And then load http: //localhost: 8080 in 
your web browser. That's it! 


® localhost:8080/#14/37.6180/-122.3710 * UU i\ © 


@ iPhone 5/SE..= 320 x 568 [J+ DPR:2+ NoThrottlings ®& 
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v GeoJSON 
{ 
"type": "Feature", 
"properties": { 
"angle": 50.9722775000288: 
"bearing": -—81.2952091166% 
"distance": 749.721862358 
}, 
"geometry": { 
"type": "GeometryCollect ic 
"geometries": [ 


{ 


The application is still in its early days. Both the user interfaces and user 
experiences lack polish and nuance while we figure out what the underlying 
scaffolding needs to support. 


I call this the "building with two-by- 
fours https://en.wikipedia.org/wiki/Lumber#Dimensional_ lumber " 


stage of development to highlight the importance of not just building things 


quickly but equally being able to disassemble and rearrange them just as 
easily. Sometimes this happens at the expense of elegance and finish but 
that doesn't diminish their importance or a commitment to address those 
things. We're just not there yet. 





negative: Mills Field Municipal Airport of San Francisco, canal 
construction. Nitrate negative. Transfer, SFO Museum Collection. 
2011.032.0002. 


Finally, do you remember the geocoding 
application https://millsfield.sfomuseum.org/blog/2019/11/04/pla 
ceholder/ [mentioned above? In the next post I will demonstrate how to 


integrate it with our geotagging application. 
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photograph: San Francisco Bay Area aerial, delta. Photograph. 
Gift of Charles Page, SFO Museum Collection. 2010.174.344. 


This was originally published on the SFO Museum Mills Field 
weblog https://millsfield.sfomuseum.org/blog/2020/04/28/ 


geotagging-search/ ,in April 2020. 


This is the fourth of an 11-part blog post about geotagging 
photos https://millsfield.sfomuseum.org/blog/tags/geotag 
ging inthe SFO Museum collection. At the end of the last 

post https://millsfield.sfomuseum.org/blog/2020/04/27/geo 


tagging-simple/ we demonstrated the foundations for our 


geotagging application, called go-www-geotag. 


The go-www-geotag application has a number of flags to 
configure its behaviour https://github.com/sfomuseum/go- 
www-geotag#server including changing the initial map view 
which, unsurprisingly, is the San Francisco International 


Airport https://millsfield.sfomuseum.org/airports/SFO 


If you wanted, for example, to open the application across the San 
Francisco Bay at the Oakland International 

Airport https://millsfield.sfomuseum.org/airports/OAK 
then you could specify its geographic coordinates at start-up, like 
this: 


$> ./bin/server \ 
-nextzen-apikey {NEXTZEN_API_KEY} \ 
-initial-latitude 37.7127 \ 
-initial-longitude -122.2118 \ 
-initial-zoom 15 


2020/04/24 16:56:32 Listening on http://localhost: 8080 


And when you open the application in your web browser you'd see 
this: 
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But what if you want to center the map on a different place and 
don't already know its latitude and longitude coordinates? What if 
you need to jump around to a bunch of different places all over the 
world? Do you remember how I mentioned the Using the 
Placeholder Geocoder at SFO 

Museum https://millsfield.sfomuseum.org/blog/2019/11/04 
/placeholder/ in the last blog 

post https://millsfield.sfomuseum.org/blog/2020/04/27/geo 


tagging-simple/ ? A'"geocoder" is exactly what we need here. 


If you're not already familiar with the term "geocoder" Wikipedia 
describes a 
geocoding https://en.wikipedia.org/wiki/Geocoding as 


" ..the process of taking input text, such as an address or the name 


of a place, and returning a latitude/longitude location on the Earth's 
surface for that place". That's what a geocoder does. 








photograph: San Francisco Bay Area aerial, Oakland port, San 
Francisco. Photograph. Gift of Charles Page, SFO Museum 
Collection. 2010.174.449. Also, look at that: San Francisco Bay 
without any bridges! 


The Using the Placeholder Geocoder at SFO 

Museum https://millsfield.sfomuseum.org/blog/2019/11/04 
/placeholder/ blog post describes how SFO Museum set up its 
own instance of the 

Placeholder https://github.com/pelias/placeholder/ 
geocoder including a custom web- 

application https: //github.com/sfomuseum/go-placeholder- 


client-www  , bundled with all its depedencies and assets, for using 


it. 


Placeholder supports global, multi-lingual "coarse" geocoding 
which means it can parse everything from continents to 
neighbourhoods, using openly licensed data, but doesn't know how 
to handle street addresses. It also does not support querying for 
airport yet which can be frustrating for us but we plan to fix that 
shortly. Overall we think the benefits of the Placeholder 


application are worth its few shortcomings. 


Rather than bundling Placeholder in to our geotagging 
application we've added support for specifying an endpoint that our 
application can talk to programatically using the Placeholder 

API https://github.com/pelias/placeholder/#open- 

browser . The details of running Placeholder are still 
sufficiently complex that it continues to makes sense to deploy it as 
a separate application. There are some promising 

developments https://github.com/google/crfs that might 
simplify things but it's too soon to know for 

sure https://github.com/sfomuseum/go-placeholder- 


client/issues/2_ yet. 


To enable Placeholder support you'd start the application like 
this: 


-/bin/server \ 
-nextzen-apikey {NEXTZEN_API_KEY} \ 
-enable-placeholder \ 
-placeholder-endpoint {PLACEHOLDER_API_ENDPOINT} 


2020/04/15 08:58:22 Listening on http://localhost:8080 


When you open the application in your web browser you'll see a 
handy search box above the map that you can query. Clicking on a 


query result will set the map's view port to that place. 


Oakland Search 










[ -] Oakland County (102083713) county 
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Support for the Placeholder API is very basic and there are still 
a lot of details to attend to. Most pressing is improving the way 
place names are displayed in the query results. As you can see from 
the screenshots, above and below, lots of places have the same 
name and the current interface for deciding which place is correct 


requires a leap of faith. 
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What we really want is something similar to the way the Pelias 
leaflet-plugin https://github.com/pelias/leaflet-plugin 


formats its results: 
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is also a geocoder. 


older sibling and knows more tricks, like resolving queries for 


addresses. Both are open source products under active development 


by the Geocode Earth hnttps://geocode.earth/ 


group. 


Ideally what we'd like is a similar Leaflet 

plugin https://leafletjs.com/examples/layers-control/ 

for the Placeholder API so that the query box, and its results, 
could be contained by the map itself. In the last 

post https://millsfield.sfomuseum.org/blog/2020/04/27/geo 


tagging-simple/ I wrote: 


I call this the “building with two-by-fours” stage of 
development to highlight the importance of not just 
building things quickly but equally being able to 
disassemble and rearrange them just as easily. 
Sometimes this happens at the expense of elegance 
and finish but that doesn’t diminish their importance 
or a commitment to address those things. We’re just 


not there yet. 


That's where we are with support for search in the go-www- 
geotag application. We've proven that the application can be 
configured to conditionally enable and make use of the 
Placeholder API. We have a basic interaction model and we 
understand how to account for its shortcomings while we continue 


to develop the rest of the application. 


After the “building with two-by-fours” stage of development is the 
"polishing the door knobs" stage where we smooth out all the rough 
edges and make things pleasant to use. It's just too soon for that 
right now. If you'd like to help out before we cycle back to 


this https://github.com/sfomuseum/go-www- 


geotag/milestones then your contributions would be 
welcome https://github.com/sfomuseum/go-www- 
geotag/issues/4 .A general purpose Leaflet plugin for the 
Placeholder API would be something that lots of different 


applications could put to good use. 





negative: San Francisco International Airport (SFO), terminal 
interior. Negative. Transfer, SFO Museum Collection. 
2011.032.0505. 


By now, you might be wondering: If go-www-geotag is a tool to 
geotag photos then... where are the photos? That's the subject of our 
next blog post. 
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model aircraft instruction book: Metalcraft Corporation. Paper, ink. Gift of the 
Captain John B. Russell Family, SFO Museum Collection. 2012.149.0814. 


This was originally published on the SFO Museum Mills Field 
weblog https://millsfield.sfomuseum.org/blog/2020/04/29/geotagging- 
images/ , in April 2020. 


This is the fifth of an 11-part blog post about geotagging 

photos https://millsfield.sfomuseum.org/blog/tags/geotagging inthe SFO 
Museum collection. At the end of the last 

post https://millsfield.sfomuseum.org/blog/2020/04/28/geotagging-search/ 


I wrote: 


By now, you might be wondering: If go-www-geotag is a tool to geotag 
photos then... where are the photos? 


If the go-www-geotag application is designed to be agnotic to the details of any one 
user's data sources how does it know where to find and load the images it's meant to 
geotag? Isn't this exactly the problem I described in the first post # in this series, a 
scenario where the go-www-geotag application is required to know about an infinite 


number of image sources? 


Developing an abstraction layer for the retrieval and publishing of cultural 
heritage materials that attempts to integrate and interface directly with an 
institution’s technical scaffolding is going to be a challenge at best and a 


fool’s errand at worst. 


Rather than trying to support a potentially infinite list of image sources we've decided 
to require the use of the oEmbed https://oembed.com/ standard as the means by 
which images are identified and loaded in to the application. oEmbed describes itself 


as: 


...a format for allowing an embedded representation of a URL on third party 
sites. The simple API allows a website to display embedded content (such 


as photos or videos) when a user posts a link to that resource... 


Essentially, it's a lightweight API that doesn't require authentication or credentials 
which, when given a URL, returns just enough information to display an image and 


suitable accreditation. 





negative: San Francisco International Airport (SFO), aerial. Negative. Transfer, 
SFO Museum Collection. 2011.032.2155. 


For example, if I call the Mills Field https://millsfield.sfomuseum.org/ 
oEmbed endpoint with the URL for this photo of planes taxiing at 


SFO https://millsfield.sfomuseum.org/objects/1511948207/ 


, at the top of 
this post, the response looks like this: 


curl -s 'https://millsfield.sfomuseum.org/oembed?url=https://millsfield.sfomuseum.org/objects/15119482 
{ 
"version": "1.0", 
"type": "photo", 
"width": "593", 
"height": "600", 
"title": "negative: San Francisco International Airport (SFO), aerial", 
"url": “https://millsfield.sfomuseum.org/media/152/782/716/7/1527827167_sHPOfBkytXcbaOEsrRqwWLarf2BmtT. 
“author_name": "SFO Museum", 
“author_url": "https://millsfield.sfomuseum.org/objects/1511948207/", 
"“provider_name": "SFO Museum", 
“provider_url": "https://millsfield.sfomuseum.org/", 


“geotag:geojson_url": "“https://millsfield.sfomuseum.org/data/1511948207/", 
“geotag:uri": "151/194/820/7/1511948207.geojson" 


The response contains a url parameter which is a pointer to an image that the go- 


www-geotag application can use to display above the map. Pretty simple, right? 


What I like about this approach is that the only thing we need to ask (museum) staff to 
do is copy and paste a URL for an object on the Mills Field 
website https://millsfield.sfomuseum.org/blog/2020/03/25/collection/ in 


order to get started geotagging photos. 


The go-www-geotag also has support for passing along an optional ?oembed- 
ur1l={URL} query parameter when opening the application in a web browser. If the 
query parameter is present the application will automatically retrieve and display the 
image associated with {URL} so staff won't even need to copy and paste anything to 
start geotagging photos. 


To enable support for oEmbed you'd start the application like this: 


-/bin/server \ 
-nextzen-apikey {NEXTZEN_API_KEY} \ 
-enable-placeholder \ 
-placeholder-endpoint {PLACEHOLDER_API_ENDPOINT} \ 
-enable-oembed \ 
-oembed-endpoints ‘https://millsfield.sfomuseum.org/oembed/?url={url}&format=json' 


2020/04/15 08:58:22 Listening on http://localhost:8080 


The -oembed-endpoints is a comma-separated list of URI 
Templates hnttps://tools.ietf.org/html/rfc6570 (RFC 6570) strings that are 
used to validate and restrict URLs and endpoints the go-www-geotag application 


can query. 


When you open the application in your web browser you'll see an input field at the top 
of the page (above the geocoder search box) where you can enter a URL to derive an 


image from. 


Enter a URL to retrieve Fetch 


Enter a place name to searc Search 
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For example, if I enter the URL 
https://millsfield sfomuseum.org/objects/1511943935/ https://millsfield.sfomu 


seum.org/objects/1511943935/ I'll see this: 


ald.sfomuseum.org/objects/1511948207/ Fetch 





negative: San Francisco International Airport (SFO), aerial 


oEmbed is not the only way to retrieve image and descriptive metadata information for 
a "resource" (for example, a collection object) on the web. There's a similar concept in 
the IIIF Presentation API documentation for IIIF manifests] 
(https://iiif.io/api/presentation/2.1/#manifest that talks about "manifest" 


files. The IIIF documentation states that: 


The manifest response contains sufficient information for the client to 
initialize itself and begin to display something quickly to the user. The 
manifest resource represents a single object and any intellectual work or 
works embodied within that object. In particular it includes the descriptive, 
rights and linking information for the object. It then embeds the sequence(s) 


of canvases that should be rendered to the user. 


Which sounds a lot like oEmbed, doesn't it? The reason we chose to start with 
oEmbed rather than IIIF is that while neither is especially complicated the former 
was simply faster and easier to set up and deploy. This echoes the rationale we talked 
about in the last blog 

post https://millsfield.sfomuseum.org/blog/2020/04/28/geotagging-search/ 
about the lack of polish, in the short-term, for the geocoding functionality in the go- 
www-geotag application: 


We have a basic interaction model and we understand how to account for its 


shortcomings while we continue to develop the rest of the application. 


We plan to add support for ILIIF manifests (there's an open 

ticket https://github.com/sfomuseum/go-www-geotag/issues/6 if you'd like to 
help out) but it was important to start with something very simple that could be 
implemented by as many institutions as possible with as little overhead as possible. It's 


not so much that IIIF is harder as it is that oEmbed is easier, if that makes sense. 


And here's how it all comes together in the go-www-geotag application: 


ald.sfomuseum.org/objects/1511948207/ Fetch 





negative: San Francisco International Airport (SFO), aerial 


Enter a place name to searc Search 
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>» GeoJSON 


Does the field of view in this image really end at the edge of the airport campus or 
should it stretch all the way up the Bay to the city of San Francisco? It's a rhetorical 
question, containing many possible answers. It's also a convenient device to describe 


some additional features of the go-www-geotag application. 





Leaflet | © OSM contributors | Nextzen | Who's On First | SFO Museuryy, 


In the first 

post https://millsfield.sfomuseum.org/blog/2020/04/23/geotagging/ of this 
series, hinting at the work to come and posting a screenshot of a geotagged 
photograph https://millsfield.sfomuseum.org/objects/1511943935/ of the 


1950s terminal building under construction, I wrote: 


As you can see the field of view for this 

photo https://millsfield.sfomuseum.org/objects/1511943935/ is 
a bit short. It should extend all the way to Sweeney Ridge to the West of the 
airport but insteads stop at the Terminal Building. 


The point being: What if we want or need to correct geotagging information in a photo 
and what happens if the go-www-geotag application loads an image that's already 
been geotagged? 


To account for these things we've updated the SFO Museum oEmbed endpoint to 
include some additional non-standard properties for images that have already been 
geotagged. When the go-www-geotag application sees these properties in a 


response it will use them to set the default camera view on the map. 


For example here's the oEmbed response, with the custom properties highlighted in 


blue, for that photo of the main terminal building under construction: 


curl -s ‘https://millsfield.sfomuseum.org/oembed?url=https://millsfield.sfomuseum.org/objects/15119439: 


{ 


"geotag:camera_longitude 
"geotag:target_latitude": "37.6163534265", 
"geotag:target_longitude": "-122.383475679", 
"geotag:angle": "41.9659437436", 

"geotag:uri": "151/194/393/5/1511943935.geojson" 


"version": "1.0", 
"type": "photo", 
"width": "784", 
"height": "600", 
"title": "negative: San Francisco Airport, Terminal Building construction", 

"url": “https://millsfield.sfomuseum.org/media/152/782/201/5/1527822015_nWTKI7fowbUEid9KjOT5£7KbFVmal 
"author_name": "SFO Museum", 

"“author_url": 
"provider_name": 
"“provider_url": "https://millsfield.sfomuseum.org/", 
"geotag:camera_latitude” 


“https: //millsfield.sfomuseum.org/objects/1511943935/", 
“SFO Museum", 








"37.6198063664", 
"-122.376408577", 


Loading the URL for that object in go-www-geotag causes the application to render 


the map, and the initial camera view, like this: 


Enter a place name to searc Search Save 
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>» GeoJSON 


And here is a screenshot with the field of view, and updated geometry information, 


extending all the way to Sweeney Ridge: 


Enter a place name to searc Search 


Save 
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v GeoJSON 
{ 
"type": "Feature", 
“properties”: { 
"angle": 26.376764049562667, 
“bearing": —127.00769014134063, 
"distance": 7636.625975614425 
}, 
"geometry": { 
“type": "GeometryCollection", 
"geometries": [ 
ih 
"type": "Point", 
"coordinates": [ 
—122.37722396850587, 
37.62021427322739 
] 
}, 


© 








Have you noticed the Save button in some of the screenshots above? We'll talk about 


that in the next blog post. 
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children’s souvenir logbook: BOAC (British Overseas Airways Corporation). 
Paper, ink. Gift of Dr. John W. Taylor, SFO Museum Collection. 2011.211.003 a b. 


This was originally published on the SFO Museum Mills Field 
weblog https://millsfield.sfomuseum.org/blog/2020/04/30/geotagging- 


writers/ ,in April 2020. 


This is the sixth of an 11-part blog post about geotagging 

photos https://millsfield.sfomuseum.org/blog/tags/geotagging inthe SFO 
Museum collection. At the end of the last 

post https://millsfield.sfomuseum.org/blog/2020/04/29/geotagging-images/ 


I wrote: 


Have you noticed the Save button in some of the screenshots above? We'll 
talk about that in the next blog post. 


So far, we've got a map and a 
camera https://millsfield.sfomuseum.org/blog/2020/04/27/geotagging- 


simple/ ,a global search 


endpoint https://millsfield.sfomuseum.org/blog/2020/04/28/geotagging- 
search/ ,asimple way to query for and display 
images https://millsfield.sfomuseum.org/blog/2020/04/29/geotagging- 


images/ and enough information to display already geotagged images correctly. 


Importantly none of these things are specific to our 

museum https://millsfield.sfomuseum.org/blog/2020/04/23/geotagging/ or 
any other institution. In fact there's nothing about go-www-geotag that is specific to 
the cultural heritage sector at all. You could use this tool to geotag any set of images. 





~~ s SS 


Installation view of The Typewriter: An Innovation in Writing. Photograph by SFO 
Museum. 


But what about saving the geotagging information that the Leaflet.GeotagPhoto 
extension produces? By default, the go-www-geotag application prints the raw 
geotagging data in to the GEoJSON pane below the map. Failing all else you could 
copy-and-paste that location information from the application to wherever it needs to 


go but that's hardly an ideal scenario. 


Enter a place name to searc Search 
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v GeoJSON 
{ 


"type": "Feature", 
“properties”: { 
"angle": 26.376764049562667, 
“bearing": —127.00769014134063, 
"distance": 7636.625975614425 
}, 
"geometry": { 
“type": "GeometryCollection", 
"geometries": [ 
{ 
"type": "Point", 
"coordinates": [ 
-122.37722396850587, 
37.62021427322739 
] 
}, 


© 





In the last 


post https://millsfield.sfomuseum.org/blog/2020/04/29/geotagging-images/ 
I said that: 


Rather than trying to support a potentially infinite list of image sources (to 
read from) we’ve decided to require the use of the oEmbed standard as the 
means by which images are identified and loaded in to the application. 


Unfortunately there isn't really a similar standard for writing data. Writing data gets in 
to all kinds of complicated issues like authentication and authorization, validations and 
transformations, and more generally workflows and editorial processes. These are all 
things that are almost never implemented the same way from one institution or 
organization to the next, nor should they be. The go-www-geotag application 
attempts to address this problem by introducing the concept of abstract 

"writers" https://github.com/sfomuseum/go-www- 
geotag/blob/master/writer/writer.go for data. In other words it tries to make all 


the details someone else's problem. 


Writers are implemented as an 

"interface" https://www.alexedwards.net/blog/interfaces-explained inthe 
Go programming language. Interfaces are sometimes also called "protocols" or 
"contracts" in other languages but the principle is the same: They define functionality 


independent of implementation that other pieces of code adhere to. 


type Writer interface { 
WriteFeature(context.Context, string, *geotag.GeotagFeature) error 


} 


The go-www-geotag.Writer interface defines a single method, called 


WriteFeature that takes three input parameters: 


e AGo language context.Context https://blog.golang.org/context 


value (which you don't need to worry about right now). 


e A unique identifier which we'll talk about in the next blog post. 


e A geotag.GeotagFeature https://github.com/sfomuseum/go-geojson- 
geotag value. This wraps the raw GeoJSON data produced by the 
Leaflet.GeotagPhoto hnttps://github.com/nypl- 
spacetime/Leaflet.GeotagPhoto plugin and provides additional 
functionality on top of that data. It also means that different writers have a 


consistent way to accept and work with geotagging data. 


At the moment the go-www-geotag application only has one built-in writer, called 
StdoutWriter, which prints its output to the terminal that you've started the 


application from. 


Here's an abbreviated example of the code https: //github.com/sfomuseum/go-www- 


geotag/blob/master/writer/stdout.go forthe StdoutWriter: 


type StdoutWriter struct { 
Writer // this declares that "StdoutWriter" will implement the methods required by "Writer" 


} 
func (wr *StdoutWriter) WriteFeature(ctx context.Context, uri string, f *geotag.GeotagFeature) error { 


body, _ := json.Marshal(f) 
br := bytes.NewReader (body) 


io.Copy(os.Stdout, br) 


return nil 


} 


A writer that simply parrots things to a terminal window has limited utility. In time we 
plan to include more sophisticated writers with the go-www-geotag application that 
might output geotagging data to a file on disk or even a database connection. 


The important thing to understand is that writers are implemented in code and, in many 
cases, code that might be specific to your application. This is where go-www-geotag 
stops being a generic application designed for multiple uses and becomes a bespoke 

tool for a dedicated purpose. We'll demonstrate an example of that in subsequent posts. 





guest book: Association of Flight Attendants, Edith Lauterbach. Paper, ink, plastic, 
metal. Gift of Edith Lauterbach, SFO Museum Collection. 2006.028.148 ae. 


The reason for requiring this level of indirection (complexity, even) is that it allows the 


go-www-geotag application to be unconcerned with how data is output or where it 


is written to. The application expects to be given a valid writer .Writer instance 
and after parsing and validating input data assumes the writer will be responsible for 


everything else. 


Here's an abbreviated example of what that looks like in code: 


import ( 
“github.com/sfomuseum/go-geojson-geotag" 
“github.com/sfomuseum/go-www-geotag/writer" 
“net/http" 

) 


func WriterHandler(wr writer.Writer) (http.Handler, error) { 
// If you're wondering: There is built-in support for "crumbs" 
// to prevent cross-site request forgeries (CSRF) in the 
// WriterHandler but we've omitted it here for the sake of brevity 


fn := func(rsp http.ResponseWriter, req *http.Request) { 


ctx := req.Context() 
query := req.URL.Query() 


uid := query.Get("id") 
geotag_f, _ := geotag.NewGeotagFeatureWithReader (req. Body) 
wr.WriteFeature(ctx, id, geotag_f) 


return 
} 
h := http.HandlerFunc(fn) 
return h, nil 
} 
wr, _ := writer.NewWriter("stdout://") 
wr_handler, _ := WriterHandler(wr) 


mux := http.NewServeMux() 
mux.Handle("/update, wr_handler) 


To enable support for writers you'd start the application like this: 


-/bin/server \ 
-nextzen-apikey {NEXTZEN_API_KEY} \ 
-enable-placeholder \ 
-placeholder-endpoint {PLACEHOLDER_API_ENDPOINT} \ 
-enable-oembed \ 
-oembed-endpoints ‘https://millsfield.sfomuseum.org/oembed/?url={url}&format=json' 
-enable-writer \ 
-writer-uri stdout:// 


2020/04/15 08:58:22 Listening on http://localhost:8080 


Once enabled the application will display a Save button over the map as soon as 


you've positioned or updated the camera. 
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When you press the Save button the application will call its internal "update" endpoint 


and you'll see something like this on the terminal console: 


2020/04/15 16:55:12 Listening on http://localhost:8080 
{"id":"151/194/350/1/1511943501.geojson", "type": "Feature", "geometry":{"type":"GeometryCollection", "geotr 


Which is the same, unformatted, data you can see in the application's GeoJSON pane. 
In the next post we'll demonstrate how to implement a custom writer that extends these 


ideas in to something a little more useful. 








negative: San Francisco International Airport (SFO), Fairchild weather signal 
receiver, Long Island. Negative. Transfer, SFO Museum Collection. 2011.032.1063. 
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glass negative: Panama-Pacific International Exposition, Art Smith. Glass 
negative. Gift of Edwin I. Power, Jr. and Linda L. Liscom, SFO Museum Collection. 
2010.282.077 a b. 


This was originally published on the SFO Museum Mills Field 
weblog https://millsfield.sfomuseum.org/blog/2020/05/01/geotagging- 


custom-writers/ ,in May 2020. 


This is the seventh of an 11-part blog post about geotagging 

photos https://millsfield.sfomuseum.org/blog/tags/geotagging inthe SFO 
Museum collection. In the last 

post https://millsfield.sfomuseum.org/blog/2020/04/30/geotagging- 


writers/ I wrote: 


A writer that simply parrots things to a terminal window has limited utility. 
In the next post we'll demonstrate how to implement a custom writer that 


extends these ideas in to something a little more useful. 


By default the go-www-geojson application produces data encoded in the 
GeoJSON https://tools.ietf.org/html/rfc7946 format. SFO Museum also 
publishes all its open data https://github.com/sfomuseum-data/ in the 
GeoJSON format, but structured as Who's On 

First https://millsfield.sfomuseum.org/blog/tags/whosonfirst (WOF) 


documents. 


In order to integrate the go-www-geojson application with our work that means we 
need to take the following steps given a GEoJSON record produced by the geotagging 


application: 


e Find the WOF record associated with the image being geotagged. 


e Update that record's geometry coordinates with the latitude and 


longitude of the go-www-geotag camera's position. 


e Update that record's property dictionary to include all the relevent 
geotagging information so that it can be used to preload an image in the 
geotagging application (like we demonstrated in part 
5 https://millsfield.sfomuseum.org/blog/2020/04/29/geotagging- 
images/ ) or ona map on the Mills 


Field nttps://millsfield.sfomuseum.org website. 


e Create or update an "alternate 


geometry https://millsfield.sfomuseum.org/blog/2019/01/14/gate 
s/ "record containing the coordinates for the go-www-geotag 


camera's field of view. 


e Publish both the primary and the alternate WOF records. 


In the last 
post https://millsfield.sfomuseum.org/blog/2020/04/30/geotagging- 


writers/ I wrote that: 


The reason for requiring this level of indirection [in the way the application 
handles writing data] is that it allows the go-www-geotag application to be 
unconcermed with how data is output or where it is written to. The 
application expects to be given a valid writer.Writer instance and after 
parsing and validating input data assumes the writer will be responsible for 
everything else. 


There's quite a lot going on in the SFO Museum scenario I've just described but the 
go-www-geotag application remains unaware of these details. We simply create an 
SFO Museum specific writer .Writer instance and tell the geotagging application 
to use that when it needs to write data. 





negative: San Francisco International Airport (SFO), construction and 
maintenance equipment. Negative. Transfer, SFO Museum Collection. 
2011.032.1703. 


In part 2 https://millsfield.sfomuseum. org/blog/2020/04/24/geotagging- 


first-steps/ of this series I wrote that: 


Go applications can be pre-compiled in to operating system specific binary 
applications that don’t require any additional steps or dependencies to run. 


That's one of the great things about developing applications in the Go programming 
language https://golang.org .One of the challenging things about developing 
applications in Go, a consequence of their ability to be baked in to pre-compiled 
binaries, is that those applications need to know about everything they're going to do in 


advance. 


In order to support SFO Museum's use case we would need to bundle all of the code 
required to implement the steps described above with the go-www-geotag 
application. That's a lot of functionality which may not be germane to another user of 
the application. It's also, potentially, a lot of code that SFO Museum may not want or 
be able to share publicly. It's a scenario that would have to be repeated for every 
custom writer adding unnecessary complexity and size to the final geotagging 
application. 





negative: San Francisco International Airport (SFO), hovercraft. Negative. 


Transfer, SFO Museum Collection. 2011.032.1321. 


It would be much better to move the SFO Museum specific code, which we'll refer to 
as the WhosOnFirstGeotagWriter https: //github.com/sfomuseum/go-www- 
geotag-whosonfirst/blob/master/writer/whosonfirst.go writer, in to its own 
package https://github.com/sfomuseum/go-www-geotag-whosonfirst/ complete 


with its own instance of the go-www-geotag application. 


In order to facilitate this approach we've tried to structure the code used to configure 
and start a geotagging application, in the go-www- 

geotag https://github.com/sfomuseum/go-www-geotag package, in to discrete 
libraries and re-usable building blocks that can make developing a custom application 


quick and easy. 


Here's an abbreviated example of the application 

code https://github.com/sfomuseum/go-www-geotag- 
whosonfirst/blob/master/cmd/server/main.go from the go-www-geotag- 
whosonfirst https://github.com/sfomuseum/go-www-geotag-whosonfirst 
package which is almost identical to the application 

code https://github.com/sfomuseum/go-www- 
geotag/blob/master/cmd/server/main.go in the go-www- 


geotag https://github.com/sfomuseum/go-www-geotag package: 


import ( 
"context" 
"github.com/sfomuseum/go-flags" 
“github.com/sfomuseum/go-www-geotag/app" 
_ “github.com/sfomuseum/go-www-geotag-whosonfirst/writer" 
“net/http" 

) 


func main() { 
£1, _ := app.CommonFlags() 


flags.Parse(fl) 
flags.SetFlagsFromEnvVars(fl, "GEOTAG") 


ctx : 
mux : 


= context.Background() 

= http.NewServeMux() 
app.AppendAssetHandlers(ctx, fl, mux) 
app.AppendEditorHandler(ctx, fl, mux) 
app.AppendProxyTilesHandlerIfEnabled(ctx, fl, mux) 
app.AppendWriterHandlerIfEnabled(ctx, fl, mux) 


S, _ := app.NewServer(ctx, fl) 
s.ListenAndServe(ctx, mux) 


In fact, the only difference is the addition of the import statement for the go-www- 


geotag-whosonfirst/writer package which registers the 
WhosOnFirstGeotagWriter https: //github.com/sfomuseum/go-www-geotag- 


whosonfirst/blob/master/writer/whosonfirst.go writer implementation: 


import ( 
_ “github.com/sfomuseum/go-www-geotag-whosonfirst/writer" 


) 


The mechanics of the Go programming language dictate that sometimes you will need 
to rewrite an application from scratch in order to add custom functionality. It can be 
frustrating at moments but we think the overall benefits that Go affords outweigh its 
few shortcomings and in between we've tried to make those rewrites as simple and 


painless as possible. 


In order to start this custom geotagging application with support for the 
WhosOnFirstGeotagWriter writer you do something like this: 


$> cd go-www-geotag-whosonfirst 
$> go build -mod vendor -p bin/server cmd/server/main.go 
$> ./bin/server \ 
-nextzen-apikey {NEXTZEN_API_KEY} \ 
-enable-placeholder \ 
-placeholder-endpoint {PLACEHOLDER_API_ENDPOINT} \ 
-enable-oembed \ 
-oembed-endpoints ‘https://millsfield.sfomuseum.org/oembed/?url={url}&format=json' 
-enable-writer \ 
-writer-uri whosonfirst://?reader=fs:///usr/local/data/sfomuseum-data-collection/data&writer=si 


2020/04/14 17:02:45 Listening on http://localhost:8080 


Different writer.Writer instances are created using a URI-based syntax. The 
syntax for the StdoutWriter writer described in the last 
post https://millsfield.sfomuseum.org/blog/2020/04/30/geotagging- 


writers/ is stdout://. 


The syntax for the WhosOnFirstGeotagWriter writer described in this post is 
whosonfirst://?reader={READER}&amp;writer={WRITER}. For 


example: 


whosonfirst:// \ 
?reader=fs:///usr/local/data/sfomuseum-data-collection/data \ 
s&writer=stdout:// 


The reader={READER} and writer={WRITER} parameters are themselves URIs 
for creating abstract reader https://github.com/whosonfirst/go-reader and 
writer https://github.com/whosonfirst/go-writer implementations specific to 


the Who's On First project https://github.com/whosonfirst/go-reader , the 


details of which are out of scope for this post. In this example we're saying "read WOF 
data from a local directory" and "write WOF data to the console". 


When you load the application in a web browser it looks and behaves exactly the same 
as before. Here's a screenshot of the application being used to geotag a photograph of 
Hubert Latham flying over downtown San 

Francisco https://millsfield.sfomuseum.org/objects/1511942249/ ,in 1911: 


2ld.sfomuseum.org/objects/1511942249/ — Fetch 





postcard: downtown San Francisco, Hubert Latham’s Antoinette 


San Francisco 
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» GeoJSON 


When the Save button is pressed the application "writes" the following data: 


"id": 1511942249, 

"type": "Feature", 

"properties": { 
"geotag:angle": 48.77566073467381, 
"geotag:bearing": 76.00314592510365, 
"“geotag:camera_latitude": 37.79147283080962, 
"geotag:camera_longitude": -122.40383148193361, 
"geotag:distance”: 19737.780983653265, 
"geotag:target_latitude": 37.83418923027191, 
"geotag:target_longitude": -122.1858472295593, 
"src:alt_label": "geotag-fov", 
"srce:geom": "“sfomuseum", 
"“wofz:id": 1511942249, 
"“wof:repo": "sfomuseum-data-collection" 

y, 

"geometry": {"type":"Polygon", "coordinates": [[[-122.40383148193361,37.79147283080962],[-122.1614405 

} 
{ 

"id": 1511942249, 

"type": "Feature", 

"properties": { 
"date:cessation_lower": "1911-12-31", 


This example is actually very long so it's been put it in a box with a fixed height and a 
scrollbar. As you scroll down you can see how and where the default GEoSON data has 
been transformed and merged with the primary and alternate WOF documents for the 
photo https://millsfield.sfomuseum.org/objects/1511942249/ that has been 


geotagged. 





Installation view of the Robots as Art, Robots as Toys, Robots that Work, and 
Famous Robots exhibition (1991). Photograph by SFO Museum. 


Both records in the example above contain data that entirely is new, and previously 
unknown to the go-www-geotag application. Where did it come from? How did the 
writer know to associate the &quot;id&quot;: 1511942249 or 
&quot;wof:id&quot;: 1511942249 properties with the photo? In part 


5 https://millsfield.sfomuseum.org/blog/2020/04/29/geotagging-images/ of 


this series I wrote that: 


[W]e’ve updated the SFO Museum oEmbed endpoint to include some 


additional non-standard properties for images... 


Most of these additional properties are there to help the go-www-geotag application 
automatically set the camera position and its field of view for previously geotagged 
photos. They are optional with the exception the geotag: uri property which is 
mandatory if you've enabled writers in the application. 


For example, here's what the oEmbed response for the photo of down San Francisco 
looks like: 


$> curl -s "https://millsfield.sfomuseum.org/oembed?url=https://millsfield.sfomuseum.org/objects/15119: 
{ 

"version": "1.0", 

"type": "photo", 

"width": "800", 

"height": "502", 

"title": "postcard: downtown San Francisco, Hubert Latham’s Antoinette", 

"url": “https://millsfield.sfomuseum.org/media/152/785/548/7/1527855487_nRYhI6KyRE23XWM200PmshkDJv jw: 

"author_name": "SFO Museum", 

“author_url": "https://millsfield.sfomuseum.org/objects/1511942249/", 

"“provider_name": "SFO Museum", 

“provider_url": "https://millsfield.sfomuseum.org/", 

“geotag:geojson_url": "https://millsfield.sfomuseum.org/data/1511942249/", 

“geotagruri": "151/194/224/9/1511942249.geojson" 





In part 6 https://millsfield.sfomuseum.org/blog/2020/04/30/geotagging- 


writers/ of this series I wrote that: 


The writer.Writer interface defines a single method, called WriteFeature that 


takes three input parameters ... the second of which is a unique identifier. 


The value of the geotag: uri property in the oEmbed response is that unique 
identifier. How that identifier is defined is a detail left to the publisher of the oEmbed 
response. How that identifier is interpreted is a detail left to the writer that consumes it, 


in this case the WhosOnFirstGeotagWriter https://github.com/sfomuseum/go- 


www-geotag-whosonfirst/blob/master/writer/whosonfirst.go#L137-L153 writer. 





Installation view of the Souvenir Neckties exhibition (1992). Photograph by SFO 
Museum. 


Just like the example in the last 
post https://millsfield.sfomuseum.org/blog/2020/04/30/geotagging- 
writers/ we're still just writing data to a terminal window but this time we're writing 


different data. In the next post we'll describe how to publish that data remotely. 
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postcard: American Airlines. Paper, ink. Gift of Hiller Aviation Museum, SFO 
Museum Collection. 2007.007.010. 


This was originally published on the SFO Museum Mills Field 
weblog https://millsfield.sfomuseum.org/blog/2020/05/04/geotagging-old- 
maps/ ,in May 2020. 


This is the eighth of an 11-part blog post about geotagging 

photos https://millsfield.sfomuseum.org/blog/tags/geotagging inthe SFO 
Museum collection. In the last 

post https://millsfield.sfomuseum.org/blog/2020/05/01/geotagging-custom- 


writers/ I wrote: 


Just like the example in the last post we’re still just writing data to a 
terminal window but this time we’re writing different data. In the next post 
we’ll describe how to publish that data remotely. 


We'll actually get to that shortly but first we're going to take a surprise detour back to 
the map itself. Here's why: 


The WhosOnFirstGeotagWriter writer that we talked about in the last 

post https://millsfield.sfomuseum.org/blog/2020/05/01/geotagging-custom- 
writers/ was the first step towards building an SFO Museum specific geotagging 
application but it turns out to be generalizable enough that it could be used by any 


project that reads and writes Who's On First https: //whosonfirst.org/what 


data. 
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negative: San Francisco International Airport (SFO), exhibit at California State 
Fair. Negative. Transfer, SFO Museum Collection. 2011.032.1983. 


We've since built a third geotagging application that sits on top of the first two (go- 
www-geotag https://github.com/sfomuseum/go-www-geotag and g0-www- 
geotag-whosonfirst https: //github.com/sfomuseum/go-www-geotag- 
whosonfirst _) that is tailored exclusively to the needs of SFO Museum. Following 
the naming conventions we've adopted to date it is called go-www-geotag- 
sfomuseum https://github.com/sfomuseum/go-www-geotag-sfomuseum and I'll 


write more about it in the future. 





What's become clear as we work through geotagging photos in the SFO Museum 
collection https://millsfield.sfomuseum.org/blog/2020/03/25/collection/ iS 
that it's very useful to be able to geotag things using a map from, or near to, the same 
year that a photo was taken. The facts on the ground change often and fast enough at 
SFO that it can be hard to make sense of an old photo using a contemporary map. For 
example, the screenshot above shows where the present-day airport complex is relative 
to the airport campus in 


1946 https://millsfield.sfomuseum. org/map/#1946/16/37.6156/-122.3867 





Leaflet | @ OSM contributors | Nextzen | Who's On First | SEO Museum 
https://millsfield.sfomuseum.org/map/#20 19/19/37 .61290/-122.39404 


Last November, in a post titled Map updates, 2019 - 

2020 https://millsfield.sfomuseum.org/blog/2020/01/10/map/ we introduced 
a new interface design for toggling between historic map layers on the Mills Fields 
website https://millsfield.sfomuseum.org/map/ 


We've taken that interface design and bundled it up as a standalone layers control 
element, written in JavaScript, for use with any 

Leaflet https: //leafletjs.com/reference-1.6.0.html#control map. It's called 
leaflet-layers-control https: //github.com/sfomuseum/leaflet-layers-control 
and this is what it looks like in the go-www-geotag application, with our historic 
aerial map imagery. 


Enter a place name to searc Search 
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There are a number of similar control elements for loading and toggling layers, 
including one that comes built-in with 

Leaflet https://leafletjs.com/examples/layers-control/ _ itself, but we've 
chosen this one because we prefer the user interface, which has a simple data structure 
for defining arbitrary layers, it automatically adjusts the map based on a layer's 
minimum and maximum zoom settings and exposes keyboard shortcuts for toggling 


between layers. 


Here's an abbreviated example in code of how to use it: 


var lat 37.6172; 
var lon -122.3827; 
var zoom = 14; 


var map = L.map("map"); 
map.setView([lat, lon], zoom); 


var catalog = [ 
{"label":"1937","year":1937,"min_zoom":12,"max_zoom":17,"source":"sfogis","url":"https://mills: 
{"label":"1949","year":1949,"“min_zoom":11,"max_zoom":14,"source":"sfomuseum","identifier":"199° 
// and so on, for a complete example see: 


// https://github.com/sfomuseum/go-sfomuseum-maps/blob/master/dist/sfomuseum.maps.catalog.js 


var layers_control = new L.Control.Layers({ 
catalog: catalog, 


he 


map.addControl(layers_control); 
layers_control.addHash(); 


The final layers _control.addHash( ) statement is optional but if declared will 


update the current URL, in the browser's location bar, to include both the map's 
position and the current layer being displayed. When that URL is opened in another 
window the leaflet-layers-control code will inspect the URL and 
automatically load the correct layer. 
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Here are three different examples of the main Terminal Building 

(1953) https://millsfield.sfomuseum.org/objects/1511943935/#1988/13/37.63 
21/-122.3738 Onamap in: 

1988 https://millsfield.sfomuseum. org/objects/1511943935/#1988/13/37.6321 
/-122.3738 , 

1956 https://millsfield.sfomuseum. org/objects/1511943935/#1956/16/37.6195 
/-122.3786 and 

1997 https://millsfield.sfomuseum. org/objects/1511943935/#1997/13/37.6204 
/-122.3977_ . As you can see we're using this control in both the go-www-geotag 
application and on the Mills Field https://millsfield.sfomuseum.org/ website 


for objects that have been geotagged. Which is the point! 
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menu: Pan American World Airways. Paper, ink. Gift of Serge Mitt, SFO Museum 
Collection. 1993.01.096. 


In the first 
post https://millsfield.sfomuseum.org/blog/2020/04/23/geotagging/ inthis 


series I wrote: 


The cultural heritage sector needs as many of these small, focused, tools as 
it can produce. ... We need to learn how to scope the purpose of and our 
expectations of any single tool so that we can be generous of, and learn 
from, the inevitable missteps and false starts that will occur along the way. 


Our hope is that tools like the leaf let-layers-control help to demonstrate the 
value of designing things in a way that allows many small and discrete components to 


be carved out of a larger bespoke project, and re-used in a variety of settings. 


In addition to publishing the JavaScript code for leaflet-layers- 

control https://github.com/sfomuseum/leaflet-layers-control we've also 
published a Go "middleware" package for the control. It's called go-http-leaflet- 
layers https://github.com/sfomuseum/go-http-leaflet-layers and follows the 
same pattern as the other similar middleware packages we've talked about in parts 

two https://millsfield.sfomuseum.org/blog/2020/04/24/geotagging-first- 
steps/ and 

three https://millsfield.sfomuseum.org/blog/2020/04/27/geotagging- 


simple/ of this series. 


Here's an abbreviated code example: 


import ( 
“github.com/sfomuseum/go-http-leaflet-layers" 
"github.com/sfomuseum/go-www-geotag/www" 


) 


func main() { 


editor_opts := &www.EditorHandlerOptions{} 
editor_handler, err := www.EditorHandler(editor_opts) 
layers_opts := layers.DefaultLeafletLayersOptions() 


editor_handler = layers.AppendResourcesHandler(editor_handler, layers_opts) 


} 


I started this discussion of the leaflet-layers-control element in the context 
of an SFO Museum specific geotagging application but both the JavaScript control and 
the Go middleware handler are already bundled with the default go-www-geotag 
application. We aren't the only project that will need or want more than one map to use 
while geotagging images so it's a good piece of functionality to make part of the core 


application. 


The challenge I have right now is that I am unsure of the best way to define where the 
"catalog" files that list the different map layers to display should come from. Each 
project will have different maps so each project will have a different catalog file. 


Should catalog files be read from a command line option when the application is 
started? Should there be another text field, like the ones for search 
terms https://millsfield.sfomuseum.org/blog/2020/04/28/geotagging- 


search/ or loading 

images https://millsfield.sfomuseum.org/blog/2020/04/29/geotagging- 
images/ , that the URL to a catalog file can be entered to? Is this functionality that is 
actually best saved for a custom version of the geotagging application like SFO 


Museum's go-www-geotag-sfomuseum ? 


I don't know yet but if you have any thoughts or suggestions we'd love to hear from 
you https://github.com/sfomuseum/go-www-geotag/issues/7 .In the meantime, 
in the posts to follow, we’ll get back to discussing how to publish geotagging data 


remotely. 


TWA 


UNITED STATES ROUTE MAP 
and SOUVENIR ATLAS 








route map: TWA (Trans World Airlines). Paper, ink. Gift of David A. Abercrombie, 
in memory of Stanley A. Abercrombie, SFO Museum Collection. 2001.039.287. 
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This was originally published on the SFO Museum Mills Field 
weblog https://millsfield.sfomuseum.org/blog/2020/05/07/geotagging- 


publishing/ ,in May 2020. 


This is the ninth of an 11-part blog post about geotagging 

photos https://millsfield.sfomuseum.org/blog/tags/geotagging inthe SFO 
Museum collection. In the last 

post https://millsfield.sfomuseum.org/blog/2020/05/04/geotagging-old- 


maps/_ I wrote: 


We’ ve since built a third geotagging application that sits on top of the first 
two (go-www-geotag and go-www-geotag-whosonfirst) that is tailored 
exclusively to the needs of SFO Museum. Following the naming 
conventions we’ve adopted to date it is called go-www-geotag-sfomuseum 
and I'll write more about it in the future. 


This post is about the go-www-geotag- 


sfomuseum https://github.com/sfomuseum/go-www-geotag-sfomuseum 
application. It adds support for authenticating users and publishing data to any service 
that supports the OAuth2 https://oauth.net/ standard. Wikipedia describes 


OAuth2 https://en.wikipedia.org/wiki/OAuth as: 


[A]n open standard for access delegation, commonly used as a way for 
Internet users to grant websites or applications access to their information 


on other websites but without giving them the passwords. 


This is as good and succinct a definition, as any, of OAuth2 but it's still a little hard to 


make concrete so when Wikipedia says: 


...as a way for Internet users to grant websites or applications access to their 


information on other websites but without giving them the passwords. 


Think of it as: 


...a way for me to grant the go-www-geotag-sfomuseum access to my 
stuff on GitHub but without giving the go-www-geotag- 


sfomuseum application the password I use to log in to github.com. 


GitHub https://github.com though is just one of many services with support for 
OAuth2, so we've written our code to be specific to the standard and not any one 


implementation. 


For the purposes of this post we're using GitHub to demonstrate our work because we 
already publish all our open data on GitHub https: //github.com/sfomuseum- 
data soit is useful for our geotagging application to be able to write directory to their 
API. In the future we might update our geotagging application to talk to SFO 
Museum's own OAuth? and API endpoints. 
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menu translator: TWA (Trans World Airlines). Paper, ink. Gift of Thomas G. 
Dragges, SFO Museum Collection. 2014.095.205. 


Before we get too far in to the details it is important to distinguish a service's support 


for OAuth2 from that same service's application programming interface (API): 


e OAuth2 only concerns itself with the mechanics of authenticating a user, 
confirming that they'd like to allow another application to do stuff on their 
behalf and generating the necessary credentials for that application to do 
SO. 


e An API defines the "stuff an application can do" on a user's behalf and 
typically requires valid OAuth2 credentials to ensure a request (to do stuff) 


is legitimate. 


For the purposes of the go-www-geotag-sfomuseunm application we want to: 


e Register our geotagging application as a valid GitHub OAuth 
application hnttps://developer.github.com/apps/building-oauth- 
apps/creating-an-oauth-app/_ . The details of this are out of scope for 
this post but GitHub has excellent 
documentation hnttps://developer.github.com/apps/building- 


oauth-apps/creating-an-oauth-app/ on the subject. 


e Authenticate all users using the GitHub 


OAuth2 hnttps://developer.github.com/apps/building-oauth- 


apps/authorizing-oauth-apps/ endpoint. 


e Retrieve and store a valid GitHub OAuth2 "access token" that can be used 
to publish geotagging data using the GitHub 
API https://developer.github.com/v3/ endpoint. 


The go-www-geotag-sfomuseum application doesn't know anything about the 
GitHub API or even that it's talking to GitHub. It only knows about OAuth2 services 
(also called providers) and access tokens that it will pass toa writer.Writer 
instance, as described in part 

six https://millsfield.sfomuseum.org/blog/2020/04/30/geotagging-writers/ 
and part 

seven https://millsfield.sfomuseum.org/blog/2020/05/01/geotagging-custom- 


writers/ of this series, which is expected to handle API requests. 


Here is how the different pieces fit together today: 
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In future releases we'd like to make that relationship tree look like this: 








go-www-geotag-sfomuseum 











go-www-geotag-whosonfirst 











go-www-geotag-oauth2 











go-www-geotag 


go-http-oauth2 














The goal would be to allow other groups who are building their own custom 


geotagging applications to take advantage of the OAuth2 plumbing we've developed 


for SFO Museum's geotagging application https: //github.com/sfomuseum/go- 


www-geotag-sfomuseum . It's a little soon for that and one way to explain why is to 


demonstrate what's necessary to start the SFO Museum geotagging application. 


It looks something like this: 


$> cd go-www-geotag-sfomuseum 


$> go build -mod vendor -p bin/server cmd/server/main.go 


$> bin/server \ 


-nextzen-apikey {NEXTZEN_API_KEY} \ 


-enable-placeholder 


-placeholder-endpoint {PLACEHOLDER_API_KEY} \ 


-enable-oembed \ 


-oembed-endpoints ‘https://millsfield.sfomuseum.org/oembed/?url={url}' \ 


-enable-writer \ 


-writer-uri 'whosonfirst://?writer={whosonfirst_writer}&reader={whosonfirst_reader}&update=1l&s« 
-whosonfirst-writer-uri '‘githubapi://sfomuseum-data/sfomuseum-data-collection?access_token={acc 
-whosonfirst-reader-uri '‘githubapi://sfomuseum-data/sfomuseum-data-collection?access_token={ac¢ 


-enable-oauth2 \ 
-oauth2-scopes ‘user,repo' 


-oauth2-client-id "constant://?val={OAUTH2_CLIENT_ID}&decoder=string" \ 
-oauth2-client-secret "constant://?val={OAUTH2_SECRET}&decoder=string" \ 
-oauth2-cookie-uri “constant://?val=debug&decoder=string" \ 

-server-uri 'mkcert://localhost:8080' 


2020/05/05 11:42:37 Checking whether mkcert is installed. If it is not you may be prompted for your pa: 


2020/05/05 11:42:40 Listening on https://localhost:8080 


That's a lot to take in but the first thing to notice is that there isn't really anything that's 


inherently SFO Museum specific. The default configurations and bundled functionality 


(for example the WhosOnFirstGeotagWriter writer described in part 


seven https://millsfield.sfomuseum.org/blog/2020/05/01/geotagging-custom- 


writers/ of this series) reflect the needs of the museum but that's about it. This is 


why I am hopeful about eventually decoupling most of the functionality in the go- 


www-geotag-sfomuseum application in to a standalone go-www-geotag- 


oauth2 package. 
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menu: KLM (Royal Dutch Airlines). Paper, ink. Gift of Thomas G. Dragges, SFO 
Museum Collection. 2014.095.193. 


Until then, let's take a look at the first set of new flags, highlighted in blue, from the 


example above: 


-writer-uri 'whosonfirst://?writer={whosonfirst_writer}&reader={whosonfirst_reader}&update=1l&source=sf« 
-whosonfirst-writer-uri 'githubapi://sfomuseum-data/sfomuseum-data-collection?access_token={access_tok« 
-whosonfirst-reader-uri 'githubapi://sfomuseum-data/sfomuseum-data-collection?access_token={access_tok« 


The -writer-uri flag uses a URI-based syntax to distinguish different writers and 
query parameters to describe their properties. Sometimes those properties might be 
other URI-style descriptors. If that's the case those URI-style properties need to be 
encoded so they don't get mistaken for other properties in the root -writer-uri 
URI. 


For example: 


-writer-uri 'whosonfirst://?writer=githubapi%3A%2F%2Fsfomuseum-data%2Fsfomuseum-data-collection%3Facce: 


It can be hard to read or write URL-encoded strings and the optional - 
whosonfirst-writer-uri and -whosonfirst-reader-uri flags are 


included as a convenience so that you don't have to. 


If they are present and not-empty they will be automatically encoded and used to 
replace the {whosonfirst_writer} and {whosonfirst_reader} 
placeholder strings in the value of the -writer-uri flag. 


I'll discuss the githubapi:// URIs and their access_token= 
{access_token} placeholer strings, in the example above, later on in this post. 





menu: China Airlines. Paper, ink, fabric. Gift of Thomas G. Dragges, SFO Museum 
Collection. 2001.080.104. 


The second set of flags tells the application to enable support for OAuth? and to define 
the scope of that support as user and repo. These are arbitary values defined by the 
OAuth? provider which, in this case, is 

GitHub https://developer.github.com/apps/building-oauth- 

apps /understanding-scopes-for-oauth-apps/#available-scopes ,and we are 
asking that our OAuth? application be allowed to validate the user and have access 
to repositories the user controls https: //developer.github.com/apps/building- 


oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes 


-enable-oauth2 \ 
-oauth2-scopes ‘user,repo' 


Speaking of GitHub, you may have noticed that there's almost nothing in these new 
flags that indicates we want to use it as an OAuth? provider. How does the geotagging 
application know to use GitHub as an OAuth2 provider? 


It knows because go-www-geotag-sfomuseum assigns default values for the - 
oauth2-auth-url and -oauth2-token-url flags in its own application code. 
Here's an abbreviated example from the go-www-geotag- 

sfomuseum/app/flags.go https: //github.com/sfomuseum/go-www-geotag- 


sfomuseum/blob/master/app/flags.go library: 


func AssignSFOMuseumFlags(fs *flag.FlagSet) error { 


fs.Set("enable-map-layers", "true") 
fs.Set("oauth2-auth-url", "https://github.com/login/oauth/authorize" ) 
fs.Set("oauth2-token-url", "“https://github.com/login/oauth/access_token") 


This is an example of what I mean when I say the go-www-geotag- 
application reflects the needs and preferences of the museum. We know that for 
our purposes we're only ever going to publish to a single OAuth? provider so there is 


no harm in assigning fixed values for these flags. 

















menu: United Air Lines. Paper, ink. Gift of David A. Abercrombie, in memory of 
Stanley A. Abercrombie , SFO Museum Collection. 2001.039.151. 


The third set of flags are where the OAuth2 application credentials are assigned as well 
something called -oauth2-cookie-uri which I'll cover in a moment. 


-oauth2-client-id "“constant://?val={OAUTH2_CLIENT_ID}&decoder=string" \ 
-oauth2-client-secret "constant://?val={OAUTH2_SECRET}&decoder=string" \ 
-oauth2-cookie-uri “constant://?val=debug&decoder=string" 


The value for each of these flags is a URI string whose syntax is defined by the Go 
Cloud Development Kit (CDK) runtimevar 
package https://gocloud.dev/howto/runtimevar/ which describes itself as: 


...an easy and portable way to watch runtime configuration variables. 
Subpackages contain driver implementations of runtimevar for various 
services, including Cloud and on-prem solutions. You can develop your 
application locally using filevar or constantvar, then deploy it to multiple 


Cloud providers with minimal initialization reconfiguration. 


Why use runtimevar style URI strings for these flags and not others? First and 
foremost to distinguish the sensitive nature of these flags from the rest. In the example 
above the value for each flag is a plain-text string which might be okay for local 
development. In a production environment we might want to store and retrieve these 
values using Amazon's AWS Parameter 

Store https://gocloud.dev/howto/runtimevar/#awsps service which gates access 


to a limited set of roles or applications. 


Should the go-www-geotag applications standardize on the use of runtimevar 
style URI strings internally for all command line flags? Probably and that probably 
means automatically converting values that don't have a known URI scheme (or prefix) 


to use the constant: //?val= syntax. 


The details of this effort is a little more complicated than they might seem on the 
surface and out of scope for this post. The Go CDK also defines a separate abstraction 
layer around secrets https://gocloud.dev/howto/secrets/ and related 

services https://medium.com/@ZeroDeth/aws-secrets-manager-vs-parameter- 
store-606d4ee2af88_, distinct from "runtime variables", that bears investigation. For 


these reasons the use of runtimevar URIs is limited to the flags described above. 
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menu: Air New Zealand, Business Class. Paper, ink, metal. Gift of Adan Wong, SFO 
Museum Collection. 2006.034.010. 


The fourth and final flag is the -server-uri flag and looks like this: 


-server-uri 'mkcert://localhost:8080' 


The go-www-geotag applications use the go-http- 
server https://github.com/aaronland/go-http-server package for serving web 
applications because it offers a simple interface for running applications in different 


environments. The mkcert: // URI scheme is described as: 


A thin wrapper to invoke the mkcert tool to generate locally signed TLS 
certificate and key files. Once created this implementation will invoke the 


tls:// scheme with the files create by mkcert. 


The documentation for the mkcert https://github.com/FiloSottile/mkcert tool 


says that: 


Using certificates from real certificate authorities (CAs) for development 
can be dangerous or impossible (for hosts like example.test, localhost or 
127.0.0.1), but self-signed certificates cause trust errors. Managing your 
own CA is the best solution, but usually involves arcane commands, 
specialized knowledge and manual steps. mkcert automatically creates and 
installs a local CA in the system root store, and generates locally-trusted 


certificates. 


If all of this talk about certificates and authorities and localhost is brand new to you the 
Let's Encrypt https://letsencrypt.org/about/ project's "Certificates for 


localhost https://letsencrypt.org/docs/certificates-for-localhost/ 


document is a good place to start. 


Using the mkcert:// prefix in the -server-uri flag will automate the work 


necessary for our geotagging application to run, locally, using an encrypted connection: 


2020/05/05 11:42:40 Listening on https://localhost: 8080 





menu: Finnair, Business Class. Paper, ink, metal. Gift of Ian H. Dally of Auckland, 
New Zealand, SFO Museum Collection. 2007.086.059. 


To understand why we go to all this trouble I need to explain how the OAuth2 
integration works in the go-www-geotag-sfomuseum application. OAuth2 
support is provided using the go-http-oauth2 github.com/sfomuseum/go-http- 


oauth2 package. In broad strokes it exports three web application "handlers": 


e The first sends a user to the OAuth2 provider to authenticate and authorize 
their account with the go-www-geotag-sfomuseunm application. 


e The second handles authorization responses from the OAuth2 provider and 


stores that authorization (in the form of an "access token") in an encrypted 


cookie on the user's browser. 


e The third is a "middleware" handler, like those discussed in parts 
two https://millsfield.sfomuseum.org/blog/2020/04/24/geotaggin 
g-first-steps/ , 
three https://millsfield.sfomuseum.org/blog/2020/04/27/geotaggi 
ng-simple/ and 
eight https://millsfield.sfomuseum. org/blog/2020/05/04/geotaggi 
ng-old-maps/ of this series, that ensures the presence and validity of the 
encrypted access token cookie. If the cookie is missing the user is 
redirected to the first handler causing them to be sent to the OAuth2 


provider to reauthorize access to their account. 


Here's an abbreviated version of what that looks like in code: 


import ( 
"context" 
"flag" 
geotag_app “github.com/sfomuseum/go-www-geotag/app" 
sfom_app "github.com/sfomuseum/go-www-geotag-sfomuseum/app" 
oauth2_flags “github.com/sfomuseum/go-http-oauth2/flags" 
oauth2_www “github.com/sfomuseum/go-http-oauth2/www" 


) 
func main() { 


fs, _ := geotag_app.CommonFlags() 
sfom_app.AppendSFOMuseumF lags (fs) 


flags.Parse(fs) 
sfom_app.AssignSFOMuseumF lags (fs) 


ctx := context.Background() 
oauth2_opts, _ := oauth2_flags.OAuth2OptionsWithFlagSet(ctx, fs) 
editor_handler, _ := geotag_app.NewEditorHandler(ctx, fs) 


editor_handler = oauth2_www.EnsureOAuth2TokenCookieHandler(oauth2_opts, editor_handler) 


writer_handler, _ := sfom_api.WriterHandler(...) 
writer_handler, _ = geotag_app.AppendCrumbHandler(ctx, fs, writer_handler) 
writer_handler = oauth2_www.EnsureOAuth2TokenCookieHandler(oauth2_opts, writer_handler) 


auth_handler := oauth2_www.OAuth2TokenCookieAuthorizeHandler(oauth2_opts) 
token_handler := oauth2_www.OAuth2AccessTokenCookieHandler(oauth2_opts) 
mux := http.ServeMux() 


mux.Handle("/", editor_handler) 
mux.Handle("/writer", writer_handler) 
mux.Handle("/signin/", auth_handler) 
mux.Handle("/auth/", token_handler) 


Encrypted cookies are handled using the go-http- 

cookie https://github.com/aaronland/go-http- 
cookie/blob/master/encrypted.go package, which uses the 

secretbox https://godoc.org/golang.org/x/crypto/nacl/secretbox and 
memguard https://github.com/awnumar/memguard packages for locking and 


unlocking the OAuth2 access token itself. The -oauth2-cookie-uri flag 


mentioned above is how you configure the encrypted cookie. 


Encrypted cookies are defined using their own URI-style syntax in the form of: 


encrypted: //?name={NAME} &secret={SECRET}&salt={SALT} 


For example: 


encrypted: //?name=c&secret=MqDptuvnXwyODSaw7NTtiDYsp9K1LKAR&salt=P2eJxT9L5sJAeMxLKaOgI f£F89NkDdvoJ 


And then finally, because we are using runtimevar URI strings for OAuth2 cookie 
URIs: 


-oauth2-cookie-uri “constant://?val=encrypted$3A%2F%2F%3Fname%3Dc%26secret%3DMqDptuvnXwyODSaw7NTtiDYsp: 


Unlike the -writer-uri flag described above there is still no convenience flag for 
defining the ?val= parameter for OAuth2 cookie URIs as a separate non-URL- 
encoded string. 


If the value of the OAuth2 cookie URI is the string "debug" then the application will 
automatically configure an encrypted cookie URI with random values. This can be 
useful for testing things but remember that you will need to clear your cookies (for 
localhost: 8080) everytime you restart the geotagging application because 
otherwise you won't be able to decrypt the last cookie that the application set. 





menu 





menu: United Air Lines. Paper, ink. Gift of David A. Abercrombie, in memory of 


Stanley A. Abercrombie , SFO Museum Collection. 2001.039.148. 


Should we be storing a user's OAuth? access token in a cookie, encrypted or not? 
Absolutely not if the cookie is unencrypted, definitely not in a production environment 
and probably not for local development if the local environment is not using an 


encrypted connection. 


In a production environment there are better, more secure, places to store an access 
token. It is still necessary to store some kind of cookie or session variable to 
distinguish one user from another but that can be the key which looks up an access 
token in a database with restricted access. If and when we migrate our geotagging 
application to a production environment we'll need to create three new go-—http- 
oauth handlers that interact with a more secure storage layer for OAuth2 access 


tokens. 


In the meantime we've been able to use the cookie-based storage to demonstrate how 
the go-http-oauth package should work with a web application without knowing 
the details of the underlying web application. We've also been able to develop a 
geotagging application that publishes data to an OAuth2 endpoint without having to set 


up, configure and maintain a separate database for OAuth? access tokens. 


Whether or not it's overkill to require an encrypted connection for locally run web 
applications is an open question. Given that this is an application which should be 
deployed using encrypted connections in a production environment it's useful to be 
able to mirror production conditions as much as possible locally. There is also the 
cautionary tale of the Firesheep 

plugin https://en.wikipedia.org/wiki/Firesheep _, first released in 2010, before 


encrypted connections for websites were the norm: 


Firesheep was an extension for the Firefox web browser that used a packet 
sniffer to intercept unencrypted session cookies from websites such as 
Facebook and Twitter. The plugin eavesdropped on Wi-Fi communications, 
listening for session cookies. When it detected a session cookie, the tool 
used this cookie to obtain the identity belonging to that session. The 
collected identities (victims) are displayed in a side bar in Firefox. By 
clicking on a victim's name, the victim's session is taken over by the 
attacker. 


In 2020 do you really need to worry about other applications eavesdropping on HTTP 
traffic for locally run services? Probably and probably not. Probably not because if it's 
happening on your computer you might have bigger problems to attend to first. 
Probably because, from a technical perspective, it's entirely possible and not very hard 
to do. 


Locally created and signed certificates, like the ones produced by the 

mkeert https://github.com/FiloSottile/mkcert tool above, will only go so far 
in protecting you from these sorts of eavesdropping attacks. It's why the OAuth? access 
token cookie is also encrypted separately and why the geotagging application also 
employs time-sensitive "crumbs" to mitigate cross-site request 


forgery https://en.wikipedia.org/wiki/Cross-site request forgery attacks. 





menu: SAS (Scandinavian Airlines System). Paper, ink. Gift of John J. Larish, SFO 
Museum Collection. 2007.002.024. 


In part seven https://millsfield.sfomuseum.org/blog/2020/05/01/geotagging- 


custom-writers/ of this series I wrote: 


The reader={READER} and writer={WRITER} parameters in the -writer- 
uri flag are themselves URIs for creating abstract reader and writer 
implementations specific to the Who’s On First project, the details of which 
are out of scope for this post. In this example we’re saying “read WOF data 


from a local directory” and “write WOF data to the console”. 


In this post we want, instead, to say "read and write WOF data from the sfomuseum- 
data-collection GitHub repository https://github.com/sfomuseum-data using 
the go-reader-github https://github.com/whosonfirst/go-reader-github and 
go-writer-github https://github.com/whosonfirst/go-writer-github packages 


respectively". 


That's what the -whosonfirst-writer-uri and -whosonfirst-reader- 
uri flags, in the earlier examples, signal. Instances of go-reader-github and 
go-writer-github both require a valid OAuth2 access token when they are 
created. Since we don't know the value of the access token when our geotagging 
application starts we instead represent the access token using a placeholder string that 


gets swapped out on demand. 


For example: 


githubapi: //sfomuseum-data/sfomuseum-data-collection?access_token={access_token}&prefix=data/ 


Normally the geotagging application creates a writer .Writer instance, as 
discussed in parts 

six https://millsfield.sfomuseum.org/blog/2020/04/30/geotagging-writers/ 
and seven https://millsfield.sfomuseum.org/blog/2020/05/01/geotagging- 
custom-writers/ of this series, when the application is started. In the go-www- 


geotag-sfomuseum application we wait until there is a request to publish data 


before creating anew writer .Writer instance swapping out the placeholder text 


with value of the current OAuth2 access token. 


Here's an abbreviated example in code https: //github.com/sfomuseum/go-www- 


geotag-sfomuseum/blob/master/api/writer.go 


func WriterHandler(wr_uri string) (http.Handler, error) { 
fn := func(rsp http.ResponseWriter, req *http.Request) { 


defer req.Body.Close() 


ctx := req.Context() 
token, _ := oauth2_www.GetOAuth2TokenContext (req) 
wr_u, _ := url.Parse(wr_uri) 
if wr_u.Scheme == "whosonfirst" { 
wr_q := wr_u.Query() 


wr_reader : 
wr_writer : 


= wr_q.Get("reader" ) 
= wr_q.Get("writer") 
wr_reader, _ 
wr_writer, _ 


url.QueryUnescape(wr_reader) 
url.QueryUnescape(wr_writer) 


wr_reader 
wr_writer 


strings.Replace(wr_reader, "{access_token}", token.AccessToken, -1 
strings.Replace(wr_writer, "{access_token}", token.AccessToken, -1 


wr_reader 
wr_writer 


= url.QueryEscape(wr_reader) 
= url.QueryEscape(wr_writer) 
wr_q.Set("reader", wr_reader) 
wr_q.Set("writer", wr_writer) 


wr_uri = fmt.Sprintf("“whosonfirst://?%s", wr_q.Encode()) 


} 


wr, _ := writer.NewWriter(ctx, wr_uri) 
uid, _ := sanitize.GetString(req, "id") 
geotag_ f, _ := geotag.NewGeotagFeatureWithReader (req.Body) 


wr.WriteFeature(ctx, uid, geotag_f) 


return 


} 


h := http.HandlerFunc(fn) 
return h, nil 


The access token itself is stored in the HTTP request's 

context https://blog.golang.org/context instance, having been assigned by the 
EnsureOAuth2TokenCookieHandler https: //github.com/sfomuseum/go-http- 
oauth2/blob/master/www/cookie.go middleware handler (in an earlier example 
above). This allows our geotagging application to remain unconcerned with the details 
of how or where access tokens are stored. This enables us to change the 
implementation details around those access tokens without changing any code in our 


geotagging application. 


To wrap things up here are a series of screenshots demonstrating this work, starting 


with the network traffic for the authentication flow: 


Enter a URL to retrieve Fetch 


Enter a place name to searc Search 
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Upon loading the application, no encrypted access token cookie is found, so I am 
redirected first to the /Signin page and then on to GitHub. Since I am already logged 
in to GitHub and have authorized the geotagging application I am sent directly back to 
the /auth page which finishes up the authorization process, stores an encrypted 
access token cookie and then redirects me back to the / page where I began. 


Here's a screenshot of me geotagging a photo taken from the roof of the Terminal 
Building https://millsfield.sfomuseum.org/objects/1511943951/#1946/15/37. 
6150/-122.3923 while it was under construction. It looks exactly like the application 


described in part 
five https://millsfield.sfomuseum.org/blog/2020/04/29/geotagging-images/ 


of this series: 


ald.sfomuseum.org/objects/1511943951/ Fetch 





negative: San Francisco Airport, Terminal Building construction 
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Here's a screenshot I took while debugging things to remind myself of the outstanding 
work we need to do to better trap and report error conditions. For example, a 401 
Bad credentials response from the GitHub API should not be interpreted as 
WRITE OKAY by the geotagging application: 


Enter a place name to searc Search 
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credentials [] 
</body></html> 





And here's a screenshot of that geotagging information written out as a Who's On First 
document, as described in part 

seven https://millsfield.sfomuseum.org/blog/2020/05/01/geotagging-custom- 
writers/ of this series, and successfully published to 

GitHub https://github.com/sfomuseum-data/sfomuseum-data- 


collection/commit/fbcflaf378cfb6ab84a2a07lefa7c545ced20626 
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And finally, here's the result of all that work on the Mills Field 


website https://millsfield.sfomuseum.org/objects/1511943951/#2019/14/37.6 


144/-122.3952 with a map of the same vantage point sixty-six years later: 





Negative. Transfer, SFO Museum Collection. 2011.032.0328. 


From attached handwritten note: "03947 / 4-8-53 / New pssgr term. bldg. view from 
weather bureau floor”. Black and white photographic negative depicting the construction of 
Terminal Building (later Central Terminal, now Terminal 2 / 72) at San Francisco Airport, with 
three men kneeling and working at far end of leveled ground; elevated view from adjacent 
building; dirt roads moving toward hills in background; photograph taken on April 8, 1953. 


This is object is classified as "Photograph (Negative)’, and is part of the Aviation Archive 
collection. 
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In the next post we'll discuss some of our efforts to try and shield museum staff from 
most, if not all, of the complexity that publishing data has introduced. 
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negative: San Francisco International Airport (SFO), noise abatement equipment. 
Negative. Transfer, SFO Museum Collection. 2011.032.2449. 


This was originally published on the SFO Museum Mills Field 
weblog https://millsfield.sfomuseum.org/blog/2020/05/18/geotagging- 


native/ ,in May 2020. 


This is the tenth of an 11-part blog post about geotagging 

photos https://millsfield.sfomuseum.org/blog/tags/geotagging inthe SFO 
Museum collection. At the end of the last 

post https://millsfield.sfomuseum.org/blog/2020/05/07/geotagging- 


publishing/ I wrote: 


In the next post we'll discuss some of our efforts to try and shield museum 
staff from most, if not all, of the complexity that publishing data has 
introduced. 


In part two https://millsfield.sfomuseum.org/blog/2020/04/24/geotagging- 


first-steps/ of this series I wrote: 


In the end we may deploy this application for staff as a hosted website on 
the internet but we would like to have the ability and the flexibility for staff 
to also run the application locally, from their desktop, regardless of whether 
they are using Windows or a Mac or even the Linux operating system. The 
majority of museum staff are not developers and won’t know how or be 
able, or want, to install the external dependencies that might be necessary 


for an application written in another programming language to run. 


This was an important motivating factor in our decision to choose to develop our 
geotagging application using the Go programming 
language https://golang.org 


Go applications can be pre-compiled in to operating system specific binary 


applications that don’t require any additional steps or dependencies to run. 


And to use Go, principally, as the housing for a traditional web application: 


Ultimately, the Go part of our application is little more than a web server 
wrapped around a standard HTML + JavaScript + CSS web application that 
could be run in any number of environments. That’s by design so that the 
“meat” of the application doesn’t get painted in to a corner of any single 


programming language or platform. 


In 2019, during a presentation about SFO Museum's work on the Mills Field 
website https: //www.aaronland.info/weblog/2019/04/08/post/#mw19 I said: 


We are building for the web first, rather than targeting any of the big 
platform vendors. The web embodies principles of openness and portability 
and access that best align with the needs, and frankly the purpose, of the 


cultural heritage sector. 


That still holds true but here's a quick reminder, from the last 
post https://millsfield.sfomuseum.org/blog/2020/05/07/geotagging- 
publishing/_ , to illustrate some of the complexity that was introduced in our 


geotagging application in order to support publishing data to a remote target: 


$> bin/server \ 
-nextzen-apikey {NEXTZEN_API_KEY} \ 
-enable-placeholder 
-placeholder-endpoint {PLACEHOLDER_API_KEY} \ 
-enable-oembed \ 
-oembed-endpoints ‘https://millsfield.sfomuseum.org/oembed/?url={url}' \ 
-enable-writer \ 
-writer-uri 'whosonfirst://?writer={whosonfirst_writer}&reader={whosonfirst_reader}&update=1&s« 
-whosonfirst-writer-uri 'githubapi://sfomuseum-data/sfomuseum-data-collection?access_token={acc 
-whosonfirst-reader-uri '‘githubapi://sfomuseum-data/sfomuseum-data-collection?access_token={acc 
-enable-oauth2 \ 
-oauth2-scopes ‘user,repo' \ 
-oauth2-client-id "constant://?val={OAUTH2_CLIENT_ID}&decoder=string" \ 
-oauth2-client-secret "constant://?val={OAUTH2_SECRET}&decoder=string" \ 
-oauth2-cookie-uri “constant://?val=debug&decoder=string" \ 
-server-uri 'mkcert://localhost:8080' 


2020/05/05 11:42:37 Checking whether mkcert is installed. If it is not you may be prompted for your pa 
2020/05/05 11:42:40 Listening on https://localhost: 8080 


It is unrealistic to expect most museum staff to ever type that long list of commands 
and flags to start an application. It is probably unrealistic to expect most museum staff 
to ever type anything from the command line to start an application. On top of that if 
you look closely at the example above you'll see there are sensitive data (the OAuth2 
client secret, for example) that shouldn't be broadly shared with staff. A better scenario 
would be to develop a native desktop application that bundles our Go-based geotagging 
application, takes care of launching it and opens a link to the application in a web 


browser. 





Installation view of "The Flight Bag: Icon of Air Travel (2003). Photo by SFO 
Museum. 


For the purposes of this post when I say "native" I am going to be talking about macOS 
desktop applications and I am going to be talking about developing those applications 
using Apple's official application programming 

interfaces https://developer.apple.com/documentation and the 

Swift https://swift.org programming language. There are other ways to develop 
native, and more importantly cross-platform, applications using web technologies, 
notably the Apache Cordova https://cordova.apache.org/ , 

ElectronJS https://www.electronjs.org/ and React 

Native https://reactnative.dev/ projects. In the future we might revisit some of 
these tools but the decision to focus on native macOS development, right now, was 


made for three reasons: 


e Better support for bundling and controlling our Go-based geotagging 
application as an external 
process https://developer.apple.com/documentation/foundation/pr 


ocess 


e The ability to exchange messages between our geotagging application and 
a native macOS application using the 
WKScriptMessage https://developer.apple.com/documentation/web 


kit/wkscriptmessage protocols. 


e Additional functionality available to native application that isn't yet 
possible using web technologies. We don't need that functionality for this 
application but it has been necessary for other projects, that we'll write 


about another time, at SFO Museum. 


In the same way that we can wrap a traditional web application in a Go program, can 
we wrap that Go program in a native macOS application? Each platform has its own 
unique affordances and tolerances. A larger goal for the museum is recognizing the 
possibilities that each platform affords so that we might be able to treat them as a kind 
of "kit of parts" to be reconfigured as needed for future projects. 


Developing a "native application that bundles our Go-based geotagging application, 
takes care of launching it and opens a link to the application in a web browser" is not 
actually that complicated, at least not initially. Matt Holt's Packaging a Go 
application for macOS https: //medium.com/@mattholt/packaging-a-go- 
application-for-macos-f£7084b00f6b5 and Brad Greenlee's Write a Mac Menu 
Bar App in Swift https: //footle.org/2015/03/26/write-a-mac-menu-bar-app- 
in-swift/ are good examples for possible approaches. Both approaches bundle a 
copy of the geotagging application server binary and take care of starting it with all 
the flags listed above. 


Here are some problems that are common to either of these approaches: 


e How does the server binary ever get shut down? If it hasn't been shut 
down and a user quits and then relaunches the native macOS binary it will 


fail because the server binary is already running on port 8080. 


e If the geotagging application needs to be opened in a browser session then 
how does the macOS application know when and whether the web 


application is already open in an existing browser window? 


Here are a few more examples of other problems I ran in to trying to bundle the 
server binary as a simple "clickable" desktop application, following Matt Holt's 


instructions: 


> ~/sfomuseum/Geotagger.app/Contents/MacOS/run 
2020/05/07 12:58:22 Checking whether mkcert is installed. If it is not you may be prompted for your pa 
2020/05/07 12:58:22 Failed to create application server, exec: “mkcert": executable file not found in 


The mkcert https://github.com/FiloSottile/mkcert application, which was 
discussed in detail in the last 

post https://millsfield.sfomuseum.org/blog/2020/05/07/geotagging- 
publishing/ is used to create the necessary files so that the geotagging application 
can use encrypted network connections while running locally on a user's desktop. 
Because mkcert is written in the Go programming, we can compile in to native 
macOS binary and bundle is alongside the server application but the startup process 
still fails: 


May 7 14:12:55 com.apple.xpc.launchd[1] (org.sfomuseum.geotagger.12020[25469]): Service exited with al 


The mkcert application does not expose its functionality as a library that our 
geotagging application can invoke in code. Instead our geotagging application needs to 
launch mkcert as a sub-process which is not something that Apple's launchd 
service, the thing that is ultimately launching the geotagging server application, 


allows. 


Even if it did the mkcert application itself has to install the certificate files, used to 
create the secure connection between the geotagging application and user's web 
browser using the operating system's sudo command which is absolutely not allowed. 
Or rather it can be allowed but requires a lot of extra scaffolding to create a "privileged 
helper https: //developer.apple.com/library/mac/documentation/Security/Con 
ceptual/Security_Overview/Architecture/Architecture.html " which introduces 
an entirely new layer of 

complexity https://erikberglund.github.io/2016/No_ Privileged Helper Tool_ 


Left_Behind/ to manage. 


negative: San Francisco International Airport (SFO), terminal interior, security 
checkpoint. Negative. Transfer, SFO Museum Collection. 2011.032.2305. 


Maybe I could just bundle the certificate files necessary to set up an encrypted 
connection? Don't ever do this. It's a terrible idea. Any possible benefits of this 


approach are outweighed by the bad practices it fosters and the potential for bad actors 


to abuse them. Also, it doesn't solve the problem of installing the necessary certificate 
authority files so your browser will know to trust your local certificates. In a world 
where any old application could easily and silently tell your web browser what to trust 


things would get messy, complicated and ugly very quickly. 


Even if it were possible to launch the geotagging application server binary, complete 
with all the necessary command line flags, there is the potential for leaking sensitive 
data by inspecting the list of running processes on the computer where the application 
is running. For example if [run the ps https://en.wikipedia.org/wiki/Ps_(Unix 


command filtering for things matching server I see this: 


$> ps auxwww | grep server 
sfomuseum 25202 0.0 0.1 5023148 10264 22S 1:45PM 0:00.03 \ 
/usr/local/sfomuseum/Geotagger.app/Contents/MacOS/server \ 
-nextzen-apikey {SENSITIVE_DATA} \ 
-enable-placeholder \ 
-placeholder-endpoint {SENSITIVE_DATA} \ 
-enable-oembed \ 
-oembed-endpoints https://millsfield.sfomuseum.org/oembed/?url={url} \ 
-enable-writer \ 
-writer-uri whosonfirst://?writer={whosonfirst_writer}&reader={whosonfirst_reader}&update=1&so 
-whosonfirst-writer-uri githubapi://sfomuseum-data/sfomuseum-data-collection?access_token={acce 
-whosonfirst-reader-uri githubapi://sfomuseum-data/sfomuseum-data-collection?access_token={acce 
-enable-oauth2 \ 
-oauth2-scopes repo \ 
-oauth2-client-id constant://?val={SENSITIVE_DATA}&decoder=string \ 
-oauth2-client-secret constant://?val={SENSITIVE_DATA}&decoder=string \ 
-oauth2-cookie-uri constant://?val={SENSITIVE_DATA}&decoder=string \ 
-server-uri tls://localhost:8080?cert=/usr/local/sfomuseum/Geotagger.app/Contents/MacOS/localh« 


The measure of how sensitive any given value of {SENSITIVE_DATA} is will vary 
from environment to environment. The point is that it's not not-sensitive so it merits 
erring on the side of caution. Even if I build a version of the geotagging application 
with all of its sensitive data baked in to the application, removing the need for 
command line flags, there is still a risk of leaking that data using tools like the 


strings https://en.wikipedia.org/wiki/Strings (Unix command. 


For example: 


$> go build -mod vendor -o sfom-server cmd/sfom-server/main.go 
$> strings sfom-server 
- greater than zeroconstant://?val={SENSITIVE_DATA}&decoder=stringdecoding string array or slice: lei 


In short there isn't a good way to launch a locally run web application, automating the 
steps necessary to ensure secure and encrypted connections, from a native application. 
While it may be possible for the purposes of SFO Museum it's not practical. Without 
the ability to ensure secure connections to the geotagging application then the potential 
for exposing sensitive credentials, whether it's the OAuth2 application secret or an 
individual's OAuth2 access token necessary for publishing data remotely, is real. The 
likelihood of that potential ever being abused may be low but that shouldn't be our 


baseline. 
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A screenshot demonstrating macOS handling a request to open a native application, 
identified by the geotag: //oauth2 URL, following a successful authentication 
flow with GitHub. 


The approach we've taken instead is to a create a fully-fledged macOS desktop 
application that: 


e Bundles the geotagging application server binary launching it at 
startup and ensuring that it is shut 
down https://developer.apple.com/documentation/foundation/proc 
ess when the macOS application is quit. The geotagging application is 


not configured to publish data remotely using an OAuth2 access token. 


e Consists of a single "view" containing an embedded web 
view https://developer.apple.com/documentation/webkit/wkwebvie 


w pointing at the geotagging application. 


Takes care of the OAuth2 authentication 

flow https://github.com/OAuthswift/OAuthswift _, like the one 
described in the last 

post https://millsfield.sfomuseum.org/blog/2020/05/07/geotaggin 
g-publishing/_, storing a valid access token in the macOS application 


context. 


Uses the 

WKScriptMessage https://developer.apple.com/documentation/web 
kit/wkscriptmessage protocols to communicate between the 
geotagging application (by way of the embedded web browser view) and 
the macOS application. This might be used to send the OAuth2 access 
token to the web application or for the web application to end data to the 
macOS application for processing. 


1 August— 30 October, 1971 
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timetable: Air Canada, US. edition. Paper, ink. Gift of the William Hough 
Collection, SFO Museum Collection. 2009.122.037. 


In part Six https://millsfield.sfomuseum.org/blog/2020/04/30/geotagging- 


writers/ of this series I wrote: 


The important thing to understand is that writers are implemented in code 
and, in many cases, code that might be specific to your application. This is 
where go-www-geotag stops being a generic application designed for 
multiple uses and becomes a bespoke tool for a dedicated purpose. The 
reason for requiring this level of indirection (complexity, even) is that it 
allows the go-www-geotag application to be unconcerned with how data is 
output or where it is written to. The application expects to be given a 
valid writer.Writer instance and after parsing and validating input data 
assumes the writer will be responsible for everything else. 


This presents a challenge when we're running our geotagging application inside of a 
macOS application. Until now, the user-facing, browser-side of the geotagging 
application would simply hand data off to the server-side of the application and expect 
a preconfigured "writer" to take care of publishing that data. Normally, the browser- 
side of the application never sees the result produced from the data it submits but now 
it needs to. More specifically it needs to see the data that may or may not have been 
reformatted but before it's been published. 





negative: San Francisco International Airport (SFO), South Terminal 
construction. Negative. Transfer, SFO Museum Collection. 2011.032.0824. 


To account for this the go-www-geotag package now comes with a new 
writer.Writer called io:// https://github.com/sfomuseum/go-www- 
geotag/blob/master/writer/io.go .Conceptually it is similar to the stdout:// 
writer described in part 

six https://millsfield.sfomuseum.org/blog/2020/04/30/geotagging-writers/ 
except that it accepts a user-defined target, a Go language 

io.Writer https://golang.org/pkg/io/#wWriter instance, that data will be written 


to. 


For example, the target might be the application's server response 

instance https://golang.org/pkg/net/http/#Response which would allow the 
code submitting geotagging information to see the output of their request. To enable 
support for the io: // writer you'd start the geotagging application like this: 


$> bin/server \ 
-enable-editor=false \ 
-enable-writer \ 
-writer-uri io:// \ 
-disable-writer-crumb 
2020/05/14 13:51:27 Listening on http://localhost:8080 


The -disable-writer-crumb flag configures the application to skip cross-site 
request forgery checks https: //en.wikipedia.org/wiki/Cross- 
site_request_forgery which is useful for testing but shouldn't ever be enabled in a 
production environment. There is also a new -enable-editor flag which defaults 
to true but can be disabled if you only want or need to submit geotagging data 


programatically. 


These flags allow us to submit the test geotagging 

data https://github.com/sfomuseum/go-www- 
geotag/blob/master/fixtures/test.geojson included with the go-www-geotag 
package to the application's /update endpoint, from the command line, and see the 
output of the io: // writer: 


$> curl -s -X PUT -d@fixtures/test.geojson ‘http://localhost:8080/update?id=151%2F194%2F984%2F9%2F151 


{ 


"type": "Feature", 
"geometry": { 
"type": "GeometryCollection", 


"geometries": [ 


{ 

"coordinates": [ 
-122.36640930175783, 
37.61888804488137 

1, 

"type": "Point" 


he 


{ 


"coordinates": [ 


[ 
-122.40979705757145, 
37.60170454665891 

l, 

[ 
-122.41460335611261, 
37.614495404514365 


It looks exactly the same as the input data, which isn't very exciting. 


The concept of an io: // writer has also been extended to the Who's On First go- 
writer family of packages https: //github.com/whosonfirst/go- 
writer/blob/master/io.go so that when combined with the geotagging 
application's whosonfirst:// writer, all of which were described in part 

seven https://millsfield.sfomuseum.org/blog/2020/05/01/geotagging-custom- 
writers/ ,it becomes possible to capture the data that would normally be published 
to the sfomuseum-data-collection https: //github.com/sfomuseum- 


data/sfomuseum-data-collection GitHub repository. 


For example: 


$> bin/server \ 
-enable-editor=false \ 
-enable-writer \ 
-writer-uri 'whosonfirst://?writer={whosonfirst_writer}&reader={whosonfirst_reader}&update=1&u| 
-whosonfirst-reader-uri 'fs:///usr/local/data/sfomuseum-data-collection/data'’ \ 
-whosonfirst-writer-uri ‘io://' \ 
-disable-writer-crumb 

2020/05/14 13:53:11 Listening on http://localhost:8080 


Now when I submit the same test geotagging 


data https://github.com/sfomuseum/go-www- 


geotag/blob/master/fixtures/test.geojson I get a very different response: 


$> curl -s -X PUT -d@fixtures/test.geojson 'http://localhost:8080/update?id=151%2F194%2F984%2F9%2F151 


{ 


"id": 1511949849, 
"type": "Feature", 
"properties": { 


"geotag: 
"geotag: 


angle": 20, 
bearing": -106.54919973541514, 


"geotag:camera_latitude": 37.61888804488137, 
"geotag:camera_longitude": -122.36640930175783, 
"geotag:distance": 4209.290541392863, 
"geotag:target_latitude": 37.60809997558664, 
"geotag:target_longitude": -122.41220020684203, 
"src:alt_label": "geotag-fov", 
"sre:geom": "sfomuseum", 
"“wof:id": 1511949849, 
"“wof:repo": "sfomuseum-data-collection" 

y, 

"geometry": {"type":"Polygon", "coordinates": [[[-122.36640930175783,37.61888804488137],[-122.4146033 


} 
{ 


"id": 1511949849, 
"type": "Feature", 


Although the above looks like well-formed structured data it's actually just plain text. 


This is because: 


e The whosonfirst:// writer nttps://github.com/sfomuseum/go-www- 


geotag-whosonfirst/blob/master/writer/whosonfirst.go produces 


two valid Who's On First records for any given geotagging input. 


e It passes each record to its internal whosonfirst/go- 


writer. Writer instance which in this case is an to:// 


writer https://github.com/whosonfirst/go- 


writer/blob/master/io.go 


e That io: // writer simply parrots the record to the (geotagging 


application) response handler. 


It would be more useful to get back data serialized as a valid GeoJSON 


FeatureCollection https://tools.ietf.org/html/rfc7946#section-3.3 object 


so another writer, called featurecollection-io:// https: //github.com/sfomuseum/go- 


www-geotag-whosonfirst/blob/master/writer/featurecollection_io.go ,has 


been added to the go-www-geotag-whosonfirst package which implements 


this functionality. For example: 


$> bin/server 
-enable-editor=false \ 
-enable-writer \ 
-writer-uri ‘'whosonfirst://?writer={whosonfirst_writer}&reader={whosonfirst_reader}&update=1&u| 
-whosonfirst-reader-uri 'fs:///usr/local/data/sfomuseum-data-collection/data'’ \ 
-whosonfirst-writer-uri '‘featurecollection-io://?count_features=2' \ 
-disable-writer-crumb 


Submitting the same test geotagging data https: //github.com/sfomuseum/go-www- 
geotag/blob/master/fixtures/test.geojson I get back a valid GeoJSON 
document that I can query using the jq  https://stedolan.github.io/jq/manual/ 


tool: 


$> curl -s -X PUT -d@fixtures/test.geojson 'http://localhost:8080/update?id=151%2F194%2F984%2F9%2F151 


1511949849 // alternate geometry “field of view" WOF record 
1511949849 // principal WOF record 


How do all of these changes get handled in our geotagging application, specifically 
SFO Museum's geotagging application https: //github.com/sfomuseum/go-www- 
geotag-sfomuseum ? To answer that question let's start by looking at the command the 


native macOS application uses to launch the geotagging application: 


$> server \ 
-nextzen-apikey {NEXTZEN_APIKEY} \ 
-enable-oembed \ 
-oembed-endpoints ‘https://millsfield.sfomuseum.org/oembed?url={url}' \ 
-enable-writer \ 
-writer-uri 'whosonfirst://?writer={whosonfirst_writer}&reader={whosonfirst_reader}&update=1&s¢ 
-whosonfirst-reader-uri 'github://sfomuseum-data/sfomuseum-data-collection' \ 
-whosonfirst-writer-uri 'featurecollection-io://?count_features=2' 
-disable-writer-crumb 
2020/05/14 15:44:48 Listening on http://localhost:8080 


Note: The application is not actually launched with command line flags in case you're 
wondering about the discussion of sensitive data above. All the application flags are set 
using equivalent environment variables https: //github.com/sfomuseum/cocoa- 
www-geotag-sfomuseum/blob/master/GeoTagMac/AppDelegate.swift#L176-L184 


but I've included command line flags here for demonstration purposes. 


First, we've enabled the featurecollection-io:// writer so that the 
application's JavaScript code can capture the transformation of geotagging data in to 


multiple Who's On First records. 


Second, the -disable-writer-crumb flag is set to account for an outstanding 
logic bug https://github.com/sfomuseum/go-www-geotag/issues/10 inthe go- 


www-geotag code that modifies the writer output when it doesn't need to. 


Third, the code in the go-www-geotag-sfomuseum package appends SFO 
Museum specific JavaScript code https: //github.com/sfomuseum/go-www- 
geotag-sfomuseum/tree/master/static/javascript _ to the application. This 
custom code is invoked after the default code in the go-www-geotag package and is 


where we can reconfigure the application for SFO Museum's needs. 
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A screenshot of the SFO Museum geotagging application running inside a native 


macOS application web view. 


For example, the following is an abbreviated version of an early version the 


sfomuseum.geotag.init.js https: //github.com/sfomuseum/go-www-geotag- 


sfomuseum/blob/master/static/javascript/sfomuseum.geotag.init.js library 


which adds a historical maps layer control, as described in part 


eight https://millsfield.sfomuseum.org/blog/2020/05/04/geotagging-old- 


maps/ 


, and redefines the functionality of the application's Save button. 


window.addEventListener("load", function load(event) { 


var 


var 


de 


map. 


var 


map 


= geotag.maps.getMapById("map") ; 


layers_control = new L.Control.Layers({ 
catalog: sfomuseum.maps.catalog, 


addControl(layers_control); 


save 


= document .getElementById("writer-save");\ 


save.onclick = function(e) { 


var 
var 
var 


var 


uri = document.body.getAttribute("data-geotag-uri", uri); 
camera = geotag.camera.getCamera(); 

fov = camera.getFieldOfView(); 

on_success = function(data) { 


var wk_webview = document.body.getAttribute("data-enable-wk-webview" ); 


if ((wk_webview == “true") && (sfomuseum.webkit.isAuth())){ 
webkit.messageHandlers.publishData.postMessage(data) ; 


} 
yi 


var on_error = function(err) { 
console.log(err); 

he 

geotag.writer.write_geotag(uri, fov, on_success, on_error); 

return false; 

he 

ye 
In the SFO Museum application the Save button works almost exactly the same as the 
default geotagging application https: //github.com/sfomuseum/go-www-geotag 
except that it takes the response of the call to geotag.writer.write_geotag 
method and passes it off to something called 


webkit.messageHandlers.publishData.postMessage. 


Earlier I said that we were using "the WKScriptMessage 

protocols https: //developer.apple.com/documentation/webkit/wkscriptmessag 
e to communicate between the geotagging application and the macOS application". 
When a macOS (or iOS) application creates an embedded web view it can be 
configured to allow the exchange of messages https: //medium.com/john-lewis- 
software-engineering/ios-wkwebview-communication-using-javascript-and- 
swift-ee077e0127eb between the view and larger application and this is an example 
of that messaging. We're sending data from our web application back up to the native 


macOS application. 
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An early screenshot demonstrating using the WKScriptMessage protocols to relay 
messages from the native application to the geotagging web application. 


Importantly those messages can only be exchanged via the embedded web view. Even 


if the geotagging application, started as an external process by the macOS application, 


were opened in a web browser, 


clicking the Save button would trigger an error 


because the webkit .messageHandlers.publishData.postMessage 


function won't exist. It is only available in the context of the native application's web 


view. 
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let decoder = MKGeoJSONDecoder() 
var features: [MKGeoJSONFeature) 


if features.count == @ { 
self.showAlert(message: "Invalid GecJSON, no features") 
return 

? 


print("FEATURES", features) 





A screenshot illustrating where, in the native macOS application, geotagging data sent 
from the web application is processed. 


We began writing a geotagging application by assuming all the publications details 
would be handled a writer .Writer instance, specifically the go-writer- 

github https://github.com/whosonfirst/go-writer- 
github/blob/master/api.go writer. Because we aren't confident about being able to 
make authenticated calls securely to and from a locally run geotagging application, for 
all the reasons discussed above and in the last 

post https://millsfield.sfomuseum.org/blog/2020/05/07/geotagging- 
publishing/ we need to reimplement that functionality, specifically publishing the 


data to GitHub using an OAuth? access token, in one of two ways: 


e In the web application, using custom JavaScript code, assuming that a 
valid OAuth2 access token can be retrieved from the native application 


using WKScriptMessage messaging. 


e In the native application, using custom Swift code, assuming that the web 
application passes the data to be published using WKScriptMessage 
messaging (as demonstrated in the example above). 


In order to accomodate this new reality the application is configured to use a writer of 


type whosonfirst://?writer=featurecollection-io whose response is 


a GeoJSON FeatureCollection that is parsed and validated in custom code, whether its 
using JavaScript (in the geotagging application) or Swift (in the native macOS 
application). We've chosen to do the former https: //github.com/sfomuseum/go- 
www-geotag- 
sfomuseum/blob/master/static/javascript/sfomuseum.geotag.init.js 
assumeing that the GitHub OAuth? access token is relayed to the JavaScript code via 
its container macOS application or set as a command line option which makes 


developing and debugging the code for the geotagging application a little easier. 


eee Developer Tools - Geotag - http;//localhost:8080/#17/37.61597/-122.38483 
GO inspector Console © Debugger {} Style Editor () Performance ‘ Memory ‘NY Network Ff Acce: 
U 1 Qe Persist Logs (Disable 


All HTML CSS JS XHR Fonts Images Media WS Other 


St... Met... Domain File Cause 


PUT @ localhost:8080 update?id=151/194/597/5/1511945975.geojson&crumb=a0320dc4c308668c2... xhr 


OP... @api.github.com —_1511945975-alt-geotag-fov.geojson?ref=master xhr 
2D GET @apigithub.com —_1511945975-alt-geotag-fov.geojson?ref=master xhr 
PUT @apigithub.com —_1511945975-alt-geotag-fov.geojson?ref=master xhr 
OP... @ api.github.com 1511945975.geojson?ref=master xhr 
GET @ api.github.com 1511945975.geojson?ref=master xhr 
PUT @ api.github.com 1611945975.geojson?ref=master xhr 


© 7requests 14.61KB/18.89KB transferred Finish: 4.06 s 





A screenshot illustrating geotagging information being transformed in to a pair of 
Who's On First formatted documents and posted the sfomuseum-data-collection 
GitHub repository using the GitHub API. 


The important change that bundling our go-www-geotag-sfomuseunm application 
in a native macOS application introduces the need to write, or rewrite, code to handle 
publishing the data. It would be nice if we didn't have to reimplement that code but it 
feels like an acceptable trade-off given all the other concerns. Crucially, the web 
application developed in Go that we've been discussing throughout this series of 

posts https://millsfield.sfomuseum.org/blog/tags/geotagging hasn't changed 


or suffered a loss in functionality. 
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negative: San Francisco International Airport (SFO), anniversary celebration for 
airport engineering department. Negative. Transfer, SFO Museum Collection. 
2011.032.2059. 


Although it is very early days for a native geotagging application that we can distribute 
to staff what I like about our approach is how we've begun to settle on a model that 


allows us: 


e The ability to develop, iterate and debug interfaces and applications using 
open and web-based technologies. At their core these applications remain 
web applications first, agnostic of platform and able to be deployed in a 


number of contexts. 


e To bundle, distribute and run those web applications as part of a native 
desktop application. 


e To manage authentication and support for OAuth2 credentials via the 
native application and the ability to store user credentials using the 


security features provided by the operating system. 


e Effective and secure communications, where necessary, between the native 


application and bundled web application. 


This is what I meant earlier when I said: 


In the same way that we can wrap a traditional web application in a Go 
program, can we wrap that Go program in a native macOS application? 
Each platform has its own unique affordances and tolerances. A larger goal 
for the museum is recognizing the possibilities that each platform affords so 
that we might be able to treat them as a kind of “kit of parts” to be 


reconfigured as needed for future projects. 


We've published the source code https: //github.com/sfomuseum/cocoa-www- 
geotag-sfomuseum for our native macOS wrapper application on the SFO Museum 
GitHub account https://github.com/sfomuseum and we would welcome any 
feedback, suggestions or improvements. It lacks any kind of polish and is still very 
much geared for the needs of SFO Museum but with a little bit of work could probably 
be made to work with any go-www-geotag compatible application. 
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* Successfully wrote 151/192/424/1/1511924241.geojson 
* Successfully wrote 151/192/424/1/1511924241-alt-geotag-fov.geojson 
* '{"type":"FeatureCollection","features":[{ "id": 1511924241, "type": "Feature", "properties": { 











A screenshot illustrating the native macOS application successfully publishing 
geotagging information for a photo of a 747 lifting off from SFO. 


An obvious limitation to our approach so far is the lack of support for iOS or any non- 
Apple platforms. It's not an ideal situation but on balance it's one that SFO Museum 
can live with for the time being. If necessary the core web application can always be 
deployed as an online resource for people who can't or don't want to use a native 


macOS application. 


We could probably also build an iOS version of this application pretty easily by 
deploying the same geotagging application server binary that is bundled with the 
macOS application to the web and pointing the iOS application's embedded web view 
at that URL. This is already possible in the macOS 


application https://github.com/sfomuseum/cocoa-www-geotag- 
sfomuseum/blob/master/GeoTagMac/AppDelegate.swift where we can point toa 


separate instance of the geotagging application, running locally, which is handy during 


the development phase. 


guard let server_uri = Bundle.main.object(forInfoDictionaryKey: “ServerURI") as? String else { 
NotificationCenter.default.post(name: Notification.Name("serverError"), object: ServerErro 
return 


} 


let server_url = server_uri 
let url = URL (string: server_url) 


let use_local_server = Bundle.main.object(forInfoDictionaryKey: "UseLocalServer") as? String 


if use_local_server == nil || use_local_server != "YES" { 
NotificationCenter.default.post(name: Notification.Name("serverListening"), object: url!) 
return 


In the next and final post in this series I will discuss why I think it's important to take 
this sort of layered (and sometimes laborious) approach to developing applications both 
in the context of SFO Museum and the broader cultural heritage sector. 





negative: San Francisco Airport, 25th anniversary celebration. Negative. Transfer, 
SFO Museum Collection. 2011.032.0290. 
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five years on/ or this... 


five years on/ or this... 





This was the first "or this..." drawing. It was made on December 
31,2014 https://aaronland. info/orthis/171/314/867/5/ 
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This is a drawing from a few days 

ago https://aaronland.info/orthis/171/316/795/9/ and 
this is a drawing from late 2017, somewhere in the 

middle https://aaronland.info/orthis/171/314/962/9/ of it 
all. 
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I don't have a lot to say about the drawings themselves. I make 
them. I usually publish them somewhere. I do it again. Five years 
later there are almost a thousand of them. During that time there 
have been a few attempts at creating at online home for all those 
drawings. They've been okay but nothing special. So I made a new 


version https://aaronland.info/orthis/ 


this is aaronland / or this. 





page 2 


Some of the things I like about this newer version are: 


e Lots of whitespace and triptych-style list views. 

e Every drawing has multiple sizes to account for 
different sized screens. Every drawing has a 
"zoomable" tiled version so you can poke around the 
details. 


e Fullscreen mode for viewing zoomable images. 


e There is code to resize images dynamically and always 


keep them fully in view above the fold. 


e Keyboard (and touch) shortcuts for navigation. 


e Tags https://aaronland.info/orthis/tags/ and 


year/month/day https://aaronland.info/orthis/a 


rchives/ Style archives. 


It works well on phones, tablets, laptops and external 


monitors. 


The raw and final versions are just static files. During 
the intermediary stages there's a database but that 
database is not the source of truth and can be 
regenerated at any time. Maybe later versions of the 
site will employ fancy server-side tricks but that will be 
a layer on top of the baseline which is a static website 


that can be hosted anywhere. 


The basics still work even if JavaScript is disabled. 
Some of the fancy stuff like keeping an image visible 
above the fold or keyboard navigation won't work but 
basic image 

scaling https://developer.mozilla.org/en- 
US/docs/Web/HTML/Element/picture by screen size 
and navigation elements are unaffected by the absence 


of JavaScript. 





august 15, 2019 / or this... 


this picture is dated on or around Aug 15, 2019 and tagged orthis 





There aren't any sort of RSS or syndication feeds yet and I am still 
deciding whether there will be. The orthis 

site https://aaronland.info/orthis/ is meant to be more an 
archive than a publication or a daily feed. It's meant to be a patient 
place to find or reference an image in a future measured in weeks or 
months or years rather than something to be consumed in the 


moment. 


That doesn't need to preclude things like syndication feeds but I am 


no less prey than the next person to the desire for immediate 
response and gratification, and the bad habits that desire fosters, 
when sharing something online. The decision not to broadcast 
updates yet, or even to commit to any kind of a schedule for 
updates, is an attempt to take a deliberate step back from that 
behavioural orbit because it seems to do more harm than good these 
days. 
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Many of the earlier drawings are small because of how they were 
originally published. Some of the drawings, both old and new, are 
poor quality because of things like lighting, a dirty camera lens or 
me just not making the effort. 
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When I can I will rescan them. A few of the originals are gone, sent 
to friends in the mail or because the inks have faded beyond 


recognition. So it goes. 





You can see all the work to date here: 


https://aaronland.info/orthis/ https: //aaronland.info/orthis 
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© on that date / or this... 


#8 Today There were no orthis... drawings on this. 
05:00 
% All Unread 
% Starred june 07, 2016 / or this... 
is dated on or around June 07, 2016 and. 
On My Mac Jun 7, 2020 . 
june 07, 2015 / or 
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is dated on or around June 07, 
2015 and tagged chalk and orthis 


I think I've found a way to be comfortable publishing syndication 
feeds for the or this archive https://aaronland.info/orthis/ 
website. This is what I wrote about my reluctance in the last 

post https://www.aaronland. info/weblog/2020/05/26/fold/#o0 


rthis announcing the site: 


There aren't any sort of RSS or syndication feeds yet 
and I am still deciding whether there will be. The 
orthis site https://aaronland.info/orthis/ 1S 
meant to be more an archive than a publication or a 
daily feed. It's meant to be a patient place to find or 
reference an image in a future measured in weeks or 
months or years rather than something to be 


consumed in the moment. 


That doesn't need to preclude things like syndication 
feeds but Iam no less prey than the next person to 
the desire for immediate response and gratification, 
and the bad habits that desire fosters, when sharing 
something online. The decision not to broadcast 
updates yet, or even to commit to any kind of a 
schedule for updates, is an attempt to take a 
deliberate step back from that behavioural orbit 
because it seems to do more harm than good these 


days. 


Rather than publishing new drawings in a syndication feed I've set 
things up to publish an "on this day" style feed. The feed will be 
regenerated every day and contain pointers to drawings that were 
done on that day in past years. | like this approach because it 
emphasizes the practice of revisiting 

things https://www.aaronland. info/weblog/2020/04/06/futur 
es/ .1| like it because it fosters a relationship between drawings 


over time. 


"On this date" is a pretty arbitrary, and pretty meaningless, framing 


device but it's still a good device so I'm going to stick with it for 
now. It reminds me of the short-lived oh yeah 

that https://aaronland. info/weblog/2014/03/15/ephemera/#o 
hyeahthat website that I ran for a time in 2014. Writing about it, 
I said: 


The belief that a tool needs to be greedier and 
greedier of a person's time and attention in order to... 
well, that's the question I suppose. The net result are 
tools that, whatever the motive or lack thereof, feel 
like their sole aim is to become the activity rather 
than complementing the things people are already 
doing. 


There should be drawings enough already to fill every day in the 
calendar (except today, as it turns out...) so that will take care of the 
year to come. With any luck there will enough new drawings from 
the rest of this year, and years to come, so that every day the past 


has something new to say. 
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bring your own pen device 


bring your own pen device 
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On or about March 8th of this year the Cooper Hewitt Smithsonian 
Design Museum pulled the 

Pen http://www. aaronland. info/weblog/2015/04/10/things/# 
mw2015 from the floor as part of a larger effort to prevent the 
spread of Covid-19. The 

Pen http://www.aaronland. info/weblog/2015/03/16/mention/ 
#breaking-up iS an interactive stylus given to every visitor that 
allowed them to collect objects on display by scanning wall labels 
with embedded NFC tags. 


March 8th was two days before the fifth anniversary of the Pen 
being officially deployed in the museum. By March, it already 


seemed clear that the Pens were set to be retired by the museum and 
I expect they will never grace the floors of the galleries again, 


regardless of whether we return to a world of communal touching. 


— 


Seb Chan @sebchan - Mar 9 Vv 

ie Noticing a lot fewer people using self checkout touchscreens at 
supermarkets ... opting to queue for a human rather than finger a public 
touchscreen ... 


0 1 ty QO 4 na 


2 thisisaaronland : 
By @thisisaaronland 


Replying to @sebchan 


what better way to celebrate the fifth anniversary of 
launching the Pen today — 
aaronland.info/weblog/2015/03... 


9:46 AM - Mar 10, 2020 - Tweetbot for iOS 


At the time we were trying to turn the Pen in to a 

reality http://www. aaronland. info/weblog/2016/03/09/osha/# 
bespokiness _ the ability to scan arbitrary NFC tags in iOS devices 
was a holy grail in museum circles, always just around the corner 
but never actually possible. It was always possible to read and write 
NEC tags in Android devices. We used an Android tablet to 
configure the NFC tags in the wall 

labels https://labs.cooperhewitt.org/2015/label-writer- 
connecting-nfc-tags-to-collection-objects/ at the Cooper 
Hewitt. The absence of that functionality in Apple products and the 


uncertainty of when it might happen meant that the so-called 


"bring your own 
device https://en.wikipedia.org/wiki/Bring_your_own_devic 


e "argument, as an alternative to developing the Pen, was moot. 


Sometime last year, four years after the Pen launched, Apple started 
shipping iOS devices with built-in NFC readers and public APIs for 
using them. Recently, I got my hands on one of those devices. I 
have a wall label from the Cooper Hewitt with an embedded NFC 
tag that we used for testing so I decided to see what it would be like 
to use an iPhone, instead of the Pen, for scanning tags and saving 


objects. 





This is the result of about a day's work, stretched over the course of 
a week. It was a way to scratch a long-standing itch and also an 
attempt to think about how we preserve some of what the Pen made 


possible in a world where we are afraid to touch anything that 


doesn't already belong to us. It's also an interesting problem for a 
museum like SFO 

Museum https://millsfield.sfomuseum.org/ which, by 
virtue of being in an 

airport http://www.aaronland. info/weblog/2015/11/09/keinh 
olz/#mcen_ , iS not in a position to hand out bespoke electronic 


hardware to its visitors. 


The application reads and parses the NFC tag in the wall label and 
then fetches the object title and image using the Cooper Hewitt 
oEmbed 

endpoint https://collection.cooperhewitt.org/oembed/ 

The Oembed https://oembed.com/ standard doesn't provide 
any means for a person to save or "collect" an object but it was the 
easiest and fastest way to prove the basic functionality of a tag- 
scanning application without getting bogged down in a lot of 
Cooper Hewitt 

API https://collection.cooperhewitt.org/api/ specific 


details. 
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Thermostat, Honeywell CT87K Round Heat- 
Only Manual Thermostat, current production 
model based on design introduced in 1953 


Clear Save 


This is similar to the approach that we've taken developing a 


general-purpose web application for geotagging 


photos https://millsfield.sfomuseum.org/blog/2020/04/29/ 


geotagging-images/ at SFO Museum, using oEmbed as a 


common means for retrieving collection information. If the 
museum sector is still looking for simple, cost-effective and 
sustainable approaches to implement cross-institutional publishing 
of their collections then providing oEmbed endpoints is a good 


place to start. I'll talk about this more later in the post. 


Once that was done, and even though I knew it wouldn't work, I 
implemented all the necessary API and authentication details to 
save an object back to my Cooper Hewitt account. 


At the same time that we launched the Pen we also enabled the 
ability for people to save objects to a 

"shoebox" https://labs.cooperhewitt.org/2015/collect- 
all-the-things/ onthe 

collection.cooperhewitt.org https://collection.cooperhewitt 
.org website. If you look at what the website is doing "under the 
hood" it's easy to see that the site itself is calling a 
cooperhewitt.shoebox.items.collectItem API 
method. Only the Cooper Hewitt website can use this API method 


and that's a decision I made five years ago. 


COOPER 


HEWITT 





See our image rights statement. 





MATCHSAFE See more objects with the color EIEN] [brown] 


2 . GEESE oF see all the colors for this object. 
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Request payload 


1 object_id=18503695Smethod=cooperhewitt. shoebox. items. collectI tenSacces: 


In retrospect that decision not to make the API method generally 
available to the public now seems, perversely, to mirror Apple's 
decision to limit access to the embedded NFC chips on its phones 


to a finite set of applications that they controlled. 


Here are some of the other things I learned, or re-learned, in the 
process of developing the application: 


e The Cooper Hewitt API does not bother with OAuth2 
client secrets and only requires an OAuth2 client ID 
when an application authenticates a 
user https://tools.ietf.org/html/rfc6749#secti 


on-4.2.1 


e The Cooper Hewitt API passes back a code 
parameter rather than a token parameter during the 


authentication flow. This appears to just be a question 
of convention and nomenclature and not a 

bug https://tools.ietf.org/html/rfc6749#secti 
on-11.2 .I wrote this code but I don't remember what 


I was thinking at the time. 


The Cooper Hewitt API does not require or return the 
state parameter during the authentication flow. This 
is not technically a bug but really ought to be treated 
like 

one https://tools.ietf.org/html/rfc6749#sectio 


n-10.12 


The you. cooperhewitt.org login endpoint does 
not forward all the query parameters on to the Cooper 
Hewitt website. The consequence of this is that the 
authentication flow will fail for people who aren't 
already logged in to the Cooper Hewitt website. This is 
definitely a bug. 


As mentioned, the 
cooperhewitt.shoebox.items.collectItem 
API method was never made available to the general 


public. 


Ready to Scan 


Hold your iPhone near the item to learn 
more about it. 


Cancel 





Reading NFC tags on a phone is still not obvious, though. 


Apple provides some default dialog messages and interface 


elements to notify a person that reading NFC tags is possible but 
there is nothing to illustrate where that person is supposed to place 
their phone over an NFC tag or the strength of a tag's signal. I have 
attempted to address this by placing an "activity indicator" in the 
application's user interface around the area around where reading 
tags works best but I doubt the NFC reader is in the same place on 
different devices. This is the sort of thing that would be useful to 


have baked in to the operating system. 


It also highlights and re-enforces the work that Timo Arnall has 
done https://www.elasticspace.com/2014/06/making- 
visible to describe how we make technologies like NFC visible 


to users. 


Y 
*) 


14:01 © 


Scan 





This object was saved to your 
device but there was a 
problem saving this object 
remotely. 

Insufficient permissions for API key 





OK 





Thermostat, Honeywell CT87K Round Heat- 
Only Manual Thermostat, current production 
model based on design introduced in 1953 


Clear Save 


Everything involving the Cooper Hewitt API is literally a "30 
minutes to a couple hours" sized project to fix but it doesn't seem 
like the museum has much of an appetite for addressing these issues 
anymore. I forfeited my right to do anything about that when I left 


the museum so it is what it is. 


Absent the ability to save objects back to my Cooper Hewitt 
account the application has the ability to also save things locally in 
a SQLite database. So far that's all it does. There is no interface for 
showing or editing saved objects yet. I would love some 

help https://github.com/aaronland/ios-wunderkammer with 
that. 


Having only one NFC-enabled wall label the application I started 
building was of limited use. Since I had eventually implemented all 
the necessary code to use the Cooper Hewitt API I realized I could 
also add a "random" button which would call the 
cooperhewitt.objects.getRandom https://collection.cooperh 
ewitt.org/api/methods/cooperhewitt.objects.getRandom 

API method and display any one of the 200,000 objects in the 
museum's collection https://collection.cooperhewitt.org 
Which I can at least save to the local database on my phone. Maybe 


some day I will able to save them to my Cooper Hewitt account. 
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Clear Save 











Assuming that Cooper Hewitt is going to retire the Pen there would 
seem to be little reason to continue producing and embedding NFC 
tags with object IDs in its wall labels. By the time the museum re- 


opens those wall labels might have been replaced too and even if I 


took my application in to the museum there wouldn't be anything to 


scan. 


That would be a shame because the underlying motivation for the 
Pen was to enable visitors to remember their visit to the museum 
without needing to spend all their time working to remember their 
visit during their time at the museum. The promise of the Pen was 
that it afforded people the means to remember an object simply by 
touching its wall label. The role of the museum in this activity was 
not to dictate the terms of that remembering, only to make it 


possible. 


Think about the number of people you see in museums taking 
pictures of objects or their wall labels. They are doing what the Pen 
was supposed to do but without any means to connect those photos 
back to the objects themselves, or the broader collection. If all those 
wall labels contained an NEC tag that broadcast an object's unique 
identifier then a museum will have taken meaningful steps towards 
making a shared remembering, a remembering that implicitly 


involves the museum, possible. 


Y 
+) 


08:11 Om 


Scan Random 





Poster, A red heart enclosed 
in a beige circle, 1957 


Clear Save 


The phrase "NFC tag" should be understood to mean "any 
equivalent technology". Everything I've described could be 
implemented using QR codes and camera-based applications. QR 


codes introduce their own aesthetic and design challenges given the 


limited space on museum wall labels but when weighed against the 
cost and complexity of deploying embedded NFC tags they might 


be a better choice for some museums. 


I still believe that the Pen was, and remains, the best physical 
means to achieve that goal of remembering but there is no denying 
that something like the Pen demands an investment in time, staff, 
capital, and now health and safety, resources outside the means of 


many institutions. 


Earlier in this post I wrote that "Jf the museum sector is still looking 
for simple, cost-effective and sustainable approaches to implement 
cross-institutional publishing of their collections then providing 
oEmbed endpoints is a good place to start." An oEmbed endpoint 
that was paired with stable identifiers embedded in wall labels 
would make it possible for any museum to offer its visitors the 


same agency to remember that the Pen did. 


"Providing an oEmbed endpoint" is not a zero-cost proposition but, 
setting aside the technical details for another post, I can say with 
confidence it's not very hard or expensive either. If a museum has 
ever put together a spreadsheet for ingesting their collection in to 
the Google Art Project, for example, they are about 75% of the way 
towards making it possible. I may build a tool to deal with the other 
25% soon but anyone on any of the digital teams in the cultural 
heritage sector could do the same. Someone should build that tool 
and it should be made broadly available to the sector as a common 


good. 


"Providing an oEmbed endpoint" does not answer the question of 
how a visitor saves or remembers an object. oEmbed simply defines 
a standard way for an application to look up information for an 
object ID stored in an NFC tag, whether its an app on your phone or 


a bespoke physical device. 


Essentially, it’s a lightweight API that doesn’t 
require authentication or credentials which, when 
given a URL, returns just enough information to 


display an image and suitable accreditation. 


Geotagging at SFO Museum, Part 5 — 
Images https: //millsfield.sfomuseum.org/blog/2020/04/29/geota 


gging-images/ 


Importantly, for the cultural heritage sector, it is simple and 
straigtforward enough that it is realistic to expect that we could all 
implement it. Critically, we could implement it for the benefit of all 
of our visitors rather than any one institution and, with the passage 


of time, to the benefit of all our collections. 
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I am not very optimistic this will ever happen but I continue to 
believe it's a goal worth pursuing. To that end I've published the 
source code for the iOS NFC tag-scanning (and random object) 


application I've been working on: 


github.com/aaronland/ios- 
wunderkammer https://github.com/aaronland/ 


ios-wunderkammer 


It should be considered an alpha-quality application. It lacks 
documentation and is still very much specific to the Cooper Hewitt. 
I will continue to improve it as time and circumstance permit, 
specifically with an eye towards making it work with any institution 
that follows a limited set of guidelines. I would love some 

help https://github.com/aaronland/ios- 


wunderkammer/issues if anyone is interested. 


I built this application because I wanted to prove that it is within the 
means of cultural heritage institutions to do what we did with the 
Pen, at Cooper Hewitt, sector-wide. I built it because it is the 


application that I want to have when I go to every museum. 


2020-06-16 


what is the sound of one action 
iteming? 


everyone gets a wunderkammer! 


everyone gets a wunderkammer! 





Joseph Cornell, Untitled, ca. 1930s, pencil on paper, Smithsonian American 
Art Museum, Gift of The Joseph and Robert Cornell Memorial Foundation, 
1985.64.5 


There have been a handful of significant updates to the 

wunderkammer https://github.com/aaronland/ios-wunderkammer 
application I talked about in the "bring your own pen 

device" https://www.aaronland. info/weblog/2020/06/16/revisiting/#p 
en blog post. The application now has the ability to work with multiple 
collections, specifically SFO 

Museum https://millsfield.sfomuseum.org/ and the whole of the 
Smithsonian https://si.edu/ . Clicking on an image will open the web 
page for that object and there is support for the operating system's "share" 
option to send an object's URL to another person or application. 


The latest releast also introduces the notion of "capabilities" for each 
collection. Some collections, like the Cooper 
Hewitt https://collection.cooperhewitt.org/ support NFC tag 


scanning and querying for random objects while some, like SFO 


Museum https://millsfield.sfomuseum.org/ and the 

Smithsonian https://si.edu/ , only support the latter. Some collections 
(Cooper Hewitt) have fully fledged API 

endpoints https://collection.cooperhewitt.org/api/ for retrieving 
random objects. Some collections (SFO Museum) have a simpler and less- 
sophisticated oEmbed endpoint for retrieving random objects. Some 
collections (Smithsonian) have neither but because the wunderkammer 
application bundles all of the Smithsonian collection data locally it's able to 


query for random items itself. 


eee wunderkammer 





model airplane: LTU International Airlines, Boeing 767-300ER (SFO 
Museum) 








In fact the wunderkammer application's own database is itself modeled as 
"collection". It doesn't have the "capability" to scan NFC tags or query for 
random objects (yet) but it does have the ability to save collection objects. 


Collections are described using a Swift https://swift.org/ language 


protocol definition that looks like this: 


public protocol Collection { 
func GetRandomURL(completion: @escaping (Result<URL, Error>) -> ()) 
func SaveObject(object: CollectionObject) -> Result<CollectionObjectSaveResponse, Error> 
func GetOEmbed(url: URL) -> Result<CollectionOEmbed, Error> 
func HasCapability(capability: CollectionCapabilities) -> Result<Bool, Error> 


func NFCTagTemplate() -> Result<URITemplate, Error> 
func ObjectURLTemplate() -> Result<URITemplate, Error> 
func OEmbedURLTemplate() -> Result<URITemplate, Error> 


Each collection implements that protocol according to its capabilities and 
specific requirements but they all present a uniform interface for 
communicating with the wunderkammer application. There is a corresponding 
CollectionOEmbed protocol that looks like this: 


public protocol CollectionOEmbed { 
func ObjectID() -> String 
func ObjectURL() -> String 
func ObjectTitle() -> String 
func Collection() -> String 
func ImageURL() -> String 
func Raw() -> OEmbedResponse 


There is still a need for an abstract collection-specific 

oEmbed https://oembed.com/ protocol because some of the necessary 
attributes, for the purposes of a wunderkammer-style application, aren't 
defined in the oEmbed specification and to account for the different ways that 
different collections return that data. To date the work on the wunderkammer 
application has used oEmbed as the storage and retrieval protocol for both 
objects which may have multiple representations and each one of those atomic 


representations that depict the same object. 
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Pump for the Iron Lung Invented by C. E. H. Armbruster 
(Gift of Charles C. Armbruster, John Lee Armbruster, 
Ruama Jane Armbruster Nelson, and Betty Louise 
Armbruster Raite Patino) (Smithsonian Institution) 
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The database models, as they are currently defined, don't necessarily account 

for or allow all the different ways people may want to do things but I've been 

modeling things using oEmbed precisely because it is so simple to extend and 
reshape. 


In the first blog 
post https: //www.aaronland. info/weblog/2020/06/16/revisiting/#pe 


n about the wunderkammer application I wrote: 


"Providing an oEmbed endpoint" is not a zero-cost proposition 
but, setting aside the technical details for another post, I can say 
with confidence it's not very hard or expensive either. If a 
museum has ever put together a spreadsheet for ingesting their 
collection in to the Google Art Project, for example, they are 
about 75% of the way towards making it possible. I may build a 
tool to deal with the other 25% soon but anyone on any of the 
digital teams in the cultural heritage sector could do the same. 
Someone should build that tool and it should be made broadly 


available to the sector as a common good. 


I remain cautiously optimistic that the simplest and dumbest thing going 
forward is simply to define two bespoke oEmbed "types": 
collection_object and collection image. Both would be 
modeled on the existing photo type with minimal additional properties to 
define an object URL alongside its object image URL and a suitable creditline. 
These are things which can be shoehorned in to the existing author and 
author_url properties but it might also be easiest just to agree on a handful 
of new key value pairs to meet the baseline requirements for showing 


collection objects across institutions. 
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Betty (Shim ogeusa) Sartok, 





career history questionnaire: World 
Wings International, Betty 
Shimogawa Santoki (SFO Museum) 
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This approach follows the work that SFO Museum has been doing to create 
the building blocks for a collection agnostic geotagging 
application https://millsfield.sfomuseum.org/blog/2020/04/29/geota 


gging-images/ 


oEmbed is not the only way to retrieve image and descriptive 


metadata information for a “resource” (for example, a collection 


object) on the web. There’s a similar concept in the ITIF 
Presentation 

API https://iiif.io/api/presentation/2.1/#manifest 
that talks about “manifest” files. The II[F documentation states 
that: 


The manifest response contains sufficient information for the 
client to initialize itself and begin to display something quickly to 
the user. The manifest resource represents a single object and any 
intellectual work or works embodied within that object. In 
particular it includes the descriptive, rights and linking 
information for the object. It then embeds the sequence(s) of 


canvases that should be rendered to the user. 


Which sounds a lot like oEmbed, doesn’t it? The reason we chose 
to start with oEmbed rather than IUF is that while neither is 
especially complicated the former was simply faster and easier to 
set up and deploy. This echoes the rationale we talked about in 
the last blog 

post https://millsfield.sfomuseum.org/blog/2020/04/28 
/geotagging-search/ about the lack of polish, in the short- 
term, for the geocoding functionality in the go-www-geotag 


application: 


We have a basic interaction model and we understand how to 
account for its shortcomings while we continue to develop the 


rest of the application. 


We plan to add support for DIF 

manifests https://iiif.github.io/training/intro-to- 
iiif/IIIF_MANIFESTS.html _ ... but it was important to start 
with something very simple that could be implemented by as 
many institutions as possible with as little overhead as possible. 
It’s not so much that IIIF is harder as it is that oEmbed is easier, if 


that makes sense. 


Almost everything that the wunderkammer application does is precisely why 


the ITF standards nttps://iiif.io exist. There would be a real and 
tangible benefit in using those standards and in time we might. I also hope that 
there is benefit in demonstrating, by virtue of not starting with IIIF, some of 
the challenges in using those standards. I have a pretty good understanding of 
how IIF is designed and meant to work but I also looked elsewhere, at the 
oEmbed specification, when it came time to try and build a working prototype. 
I offer that not as a lack of support for the IIIF project but as a well- 


intentioned critique of it. 
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Marker pen used by architect Michael Marshall (Collection 
of the Smithsonian National Museum of African American 
History and Culture, Gift from Architectural Design 
Archives, Michael Marshall, Architect) (Smithsonian 
Institution) 
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Earlier I said that "the wunderkammer application bundles all of the 
Smithsonian collection data locally". This is done by producing 

SQLite https://www.sqlite.org/ databases containing pre-generated 
oEmbed data from the Smithsonian Open Access Metadata 

Repository https://github.com/Smithsonian/OpenAccess which 
contains 11 million metadata records of which there are approximately 3 


million openly licensed object images. 


These SQLite databases are produced using two Go https://golang.org/ 
language packages, go-smithsonian- 

openaccess https://github.com/aaronland/go-smithsonian- 
openaccess for reading the Open Access data and go-smithsonian- 
openaccess-database https: //github.com/aaronland/go-smithsonian- 
openaccess-database for creating the oEmbed databases, and copied 
manually in to the application's documents folder. This last step is an 
inconvenience that needs to be automated, probably by downloading those 
databases over the internet https://github.com/aaronland/ios- 


wunderkammer/issues/14__, but that is still work for a later date. 


Here is how I created a database of objects from the National Air and Space 
Museum https://airandspace.si.edu/ 


$> cd /usr/local/go-smithsonian-openaccess-data 
$> sqlite3 nasm.db < schema/sqlite/oembed.sqlite 


$> /usr/local/go-smithsonian-openaccess/bin/emit -bucket-uri file:///usr/local/OpenAccess \ 
-oembed \ 
metadata/objects/NASM \ 
| bin/oembed-populate \ 
-database-dsn sql://sqlite3/usr/local/go-smithsonian-openaccess-database/nasm.db 
$> sqlite3 nasm.db 


sqlite> SELECT COUNT(url) FROM oembed; 
2407 


The wunderkammer application also supports multiple databases associated 
with a given collection. This was done to accomodate the Smithsonian 
collection which yields a 1.5GB document if all 3 million image records are 
bundled in to a single database file. 
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Decoupage (England) (Smithsonian 
Cooper Hewitt National Design 
Museum) 
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One notable thing about the code that handles the Smithsonian 

data https://github.com/aaronland/ios- 
wunderkammer/blob/master/wunderkammer/Smithsonian.swift is that it's 
not really specific to the Smithsonian. It is code that simply assumes 
everything about a collection is local to the device stored in one or more 
SQLite databases, with the exception being object image files that are still 
assumed to be published on the web. It is code that can, and will, be 
adapted https://github.com/aaronland/ios-wunderkammer/issues/15 


to support any collection with enough openly licensed metadata to produce 
oEmbed-style records. It is code that can support any collection regardless of 
whether or not they have a publicly available API. 


It is also code that makes possible a few other things, but I will save that for a 
future blog post. 


go-jsonl 
Go package for working with line-delimited JSON files. 
@co 4% Bsp-3-clause %0 0 Wo J20 Updated 22 hours ago 


ios-wunderkammer N 


@ swift 2 Bsp-3-clause Yo Wa @©13(5issuesneedhelp) {0 Updated 2 days ago 


go-smithsonian-openaccess-database 


@co 4 Bsp-3-clauuse YO 0 Go $40 Updated 5 days ago 


go-smithsonian-openaccess 
Go package for working with the Smithsonian Open Access release. K 


golang smithsonian 


@cGo 4% BSD-3-Clause Yo 2 @1 (lissue needs help) {0 Updated 6 days ago 


OpenAccess mn 
Forked from Smithsonian/OpenAccess KA 
Smithsonian Open Access Data Repository 


a cco-10 Y7 Yo @o %F%0 Updated 12 days ago 


The wunderkammer application itself is still very much a work in progress 
and not ready for general use, if only because it is not available on the App 
Store and requires that you build and install it manually. I don't know whether 
or not I will make the application on the App Store at all. It is a tool lam 
building because it's a tool that I want and it helps me to prove, and disprove, 
some larger ideas about how the cultural heritage sector makes its collections 


available beyond "the museum visit". 


It is code that is offered to the cultural heritage sector in a spirit of generousity 
and if you'd like to help out there is a growing list of details to attend 
to https://github.com/aaronland/ios-wunderkammer/issues in order to 


make the application better and more useful. 


eee wunderkammer 


Random 





negative: San Francisco, view of Bay Bridge and clouds 


Clear Save 
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a better kill-time experience 


so that it may be remembered 


so that it may be remembered 


// remember: something like "si://nmaahc/o/A2@18.24.1.1.1ab" 
// will never work because "." is a reserved character in RFC6570 
// https://tools.ietf.org/htm1/rfc6570#section-2.1 
264 public func NFCTagTemplate() -> Result<URITemplate, Error> { 
let t = URITemplate(template: "si://{collection}/o/{objectid}") 
return .success(t) 
+ 


public func ObjectURLTemplate() -> Result<URITemplate, Error> { 
| let t = URITemplate(template: "si://{collection}/o/{objectid}") 
return .success(t) 
+ 


public func OEmbedURLTemplate() -> Result<URITemplate, Error> { 
] let t = URITemplate(template: “oembed:///?url={url}") 
return .success(t) 

















} 
M } 
Gp il noe? ev wunderkammer 
an/nmaahc.db : aaa . 


URI Optional ("si: //nmaahc/o/A2018_24_1_1_1ab") 

TEMPLATE success(si://{collection}/o/{objectid}) 

EXTRACT si://{collection}/o/{objectid} Optional("si://nmaahc/o/A2018_24_1_1_1ab") 

VARIABLES ["collection": "nmaahc", “objectid": "A2@18_24_1_1_1ab"] 

STR URL si://nmaahc/o/A2@18_24_1_1_1ab 

TEMPLATE success(chsdm:o:{objectid}) 

EXTRACT chsdm:o:{objectid} Optional ("si://nmaahc/o/A2018_24_1_1_1ab") 

NOTHING 

OEMBED oembed: ///?url=si%3A%2F%2Fnmaahc%2Fo%2FA2@18_24_1_1 lab 

GET oembed: ///?url=si%3A%2F%2Fnmaahc%2Fo%2FA2018_24_1_1_1ab 

2020-87-89 09:40:37.605201-0700 wunderkammer[1508:287799] [CoreNFC] 90000002 80814180 -[NFCNDEFR 
setAlertMessage:]:79 (null) 


Towards the end of the everyone gets a 
wunderkammer! https: //www.aaronland. info/weblog/2020/07/07/action/#wun 


derkammer blog post I wrote: 


Code that can support any collection regardless of whether or not they 
have a publicly available API ... makes possible a few other things, but I 
will save that for a future blog post. 


Here are five short videos to illustrate what I was talking about. 





The first video shows the wunderkammer https://github.com/aaronland/ios- 
wunderkammer/ application reading a custom-made NFC tag for a first generation 
iPad which is part of the collection of the Smithsonian Cooper Hewitt National 
Design Museum https://collection.cooperhewitt.org/ .The application reads 
the tag and then uses the Cooper Hewitt 

API https://collection.cooperhewitt.org/api to look up information for that 


object. https://collection.cooperhewitt.org/objects/18797293/ 





The second video depicts the same thing but for a different object in the collection, a 
sculpture in the form of a 


banana https://collection.cooperhewitt.org/objects/18458677/ .This video 


is a bit superfluous but I discovered the object spelunking through the Cooper Hewitt 
collection using the wunderkammer application this morning so I decided to include 
it. 





The third video is for an object in the Smithsonian National Museum of African 
American History and Culture https://nmaahc.si.edu/ (NMAAHC).It'sa 
pen that belonged to the architect Michael 

Marshall https://nmaahc.si.edu/object/nmaahc_A2018.24.1.1.lab 
NMAAHC doesn't have any sort of public API for looking up objects. In this instance 
the wunderkammer application is looking up the ID in the NFC tag 

(si: //nmaahc/o/A2018_24 1 1 lab) from a local database produced from 
the Smithsonian Open Access https: //github.com/smithsonian/OpenAccess 
dataset. The object's image is being retrieved from the Smithsonian's web servers but 
all the other information is local to device that the wunderkammer application runs 
on. 


HIPPOPOTAMUS (owner ) G 





This is not really a sculpture of William the hippopotamus. I grew up with a William 
made of cloth and stuffing and would have used that for the video if I could find it. 


Instead, I made a quick approximation out of children's polymer clay. 


The fourth video is for an object in the Metropolitan Museum of 

Art https://metmuseum.org/ .It is an Egyptian sculpture of a hippopotamus 
colloquially known as 

"William https: //www.metmuseum.org/art/collection/search/544227 ". Like 
the pen in the NMAAHC collection all of the information about this object, save for 
the image, is local to the device. The local data was produced using the Metropolitan 
Museum of Art Open Access 

Initiative https://github.com/metmuseum/openaccess/ dataset and two Go 
packages for creating a wunderkammer compatible database from those objects, go- 
metmuseum-openaccess https://github.com/aaronland/go-metmuseum- 
openaccess and go-wunderkammer https://github.com/aaronland/go- 


wunderkammer 


11:53 Ce) 








Dress (Gift of Miss Irene Lewisohn, 
1941) (Metropolitan Museum of Art) 
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Here's an example of that data being filtered for objects marked as public domain and 
transformed in to OEmbed records. The output is sent directly to a tool called 
wunderkammer-db that produces a SQLite database used by the wunderkammer 
application. 


$> sqlite3 metmuseum.db < schema/sqlite/oembed.sqlite 


$> /usr/local/go-metmuseum-openaccess/bin/emit \ 
-oembed \ 
-oembed-ensure-images \ 
-with-images \ 
-bucket-uri file:///usr/local/openaccess \ 
-images-bucket-uri file:///usr/local/go-metmuseum-openaccess/data \ 


| bin/wunderkammer-db 
-database-dsn sql:///usr/local/go-wunderkammer/metmuseum.db 


$ sqlite3 metmuseum.db 
SQLite version 3.32.1 2020-05-25 16:19:56 


Enter ".help" for usage hints. 
sqlite> SELECT COUNT(url) FROM oembed; 
236288 





The fifth video is for one of my own Or 

This https://www.aaronland.info/weblog/2020/05/26/fold/#orthis drawings, 
one that I made about a week 

ago https://aaronland.info/orthis/171/326/096/9/ .Like the Smithsonian 
and Metropolitan Museum of Art datasets the wunderkammer application is retrieving 
all its data from a local "orthis" SQLite database. What's different about this video 
from the others is that the image is also being retrieved from the local database. If you 
look carefully you'll see that the phone has been disconnected from both the cellular 
and wireless networks. 


The image data is being bundled in a new, and non-standard, OEmbed property called 
data_ur1 which is a base64 encoded data 

URL https://developer.mozilla.org/en- 

US/docs/Web/HTTP/Basics_of HTTP/Data_URIs of the image. When the 
wunderkammer saves an object locally it also saves a copy of the image and this new 
property is where that data is stored. This is part of the ongoing work to settle on the 
simplest and dumbest common format for working with collection data. In the last 
blog 

post https://www.aaronland. info/weblog/2020/07/07/action/#wunderkammer 

I spoke about how all the collections in the wunderkammer application, including the 
wunderkammer's own local database of saved objects, conform to a common public 
Collection interface. That Collection interface in turn expects to work with a 


common, but modified, version of the OEmbed photo data structure. 


Here's the Go language definition for that modified data structure with the additional 


elements that the wunderkammer application uses: 


package oembed 


type Photo struct { 


ProviderName string ~json:"provider_name"~ 
ProviderURL string ~json:"provider_url"~ 
ObjectURI string ~json:"object_uri"~ 


DataURL string ~json:"data_url,omitempty"~ 


Version string ~json:"version,xml:"version""~ 
Type string ~json:"type"~ 

Width int ~json:"width"~ 

Height int ~json:"height"~ 

Title string ~json:"title"~ 

URL string ~json:"url"~ 

AuthorName string ~json:"author_name"~ 
AuthorURL string ~json:"author_url"~ 


} 


Things are still in flux but I think they are close to being done. It contains an optional 
data_url1 property and an obligatory object_uri property. Here are some 
examples of object URIs each unique to a different collection: 


e In the case of the Cooper Hewitt the object_uri is chsdm:o: 
{OBJECT_ID}. 


e In the case of the Smithsonian it is 
siz://{SMITHSONIAN_COLLECTION}/o/ {NORMALIZED _EDAN ID}. 


e In the case of the Metropolitan Museum of Art it is 
metmuseum: //o/{OPENACCESS_ID}. 


e In the case of the Or This drawings it is 
aa://orthis/{DRAWING_ID}. 


The last three examples are all well-formed URIs with scheme, host and path 
elements. In the case of the Smithsonian and the Met I made some arbitrary choices 
since they haven't published their own schemes for NFC tags yet. They all differ from 
the Cooper Hewitt NFC tag format which is a list of colon-separated elements. That 
was a decision made way back in 2014 to account for the fact that NFC tags have a 
maximum capacity of of 144 bytes. 


~ > 14:28 cs) 
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negative: San Francisco International 
Airport (SFO), Lufthansa German Airlines 
inaugural flight to SFO (SFO Museum) 


© ho 8 


It would have been, and would still be, nice to include a fully qualified address on the 
web in an NFC tag 
(https://collection.cooperhewitt.org/objects/18458677/ 
instead of chsdm:0: 18458677). We already knew then that tags would need to 
accomodate wall labels with multiple objects so we opted for semantics that favoured 
brevity while trying to limit ambiguity. For example chsdm:o0: {OBJECT_ID}, 
{OBJECT _ID},{OBJECT_ID} instead of c:o... where it's not readily obvious 


wat 


what "c" means. 


In the case of the wunderkammer application the only requirement is that an NFC tag 
contain a value which can be parsed as a RFC 6570 URI 


Template https://tools.ietf.org/html/rfc6570 . Interestingly, for the museum 
sector, this decision means that most accession numbers can't be used in tag URIs 


since the "." symbol is a reserved character in URI templates. 


In this model the object_uri becomes the primary key for the object but not for 
SQLite databases that the wunderkammer application works with. The primary key 
remains the OEmbed (photo) url property which is one of many possible 
representations of an object. Here's what the database schema for these databases 
looks like: 


CREATE TABLE oembed ( 
url TEXT PRIMARY KEY, 
object_uri TEXT, 
body TEXT 

dF 


CREATE INDEX ~by_object~ ON oembed (*object_uri® ); 


For example, there are three images of the pen owned by Michael 

Marshall https://nmaahc.si.edu/object/nmaahc_A2018.24.1.1.lab in the 
NMAAHC collection. There are 16 images of sneakers worn by Julius "Dr. J" 
Erving https://nmaahc.si.edu/object/nmaahc_2015.115.1lab_ . In fact there are 
generally many different representations, and kinds of representations, associated with 
any given object so this feels like a good way to prepare for the wunderkammer 


application to accomodate them going forward. 
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Sneakers worn by Julius "Dr. J" Erving and 
inscribed to Doc Stanley (Collection of the 
Smithsonian National Museum of African American 
History and Culture) (Smithsonian Institution) 
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As I write this the wunderkammer application only shows the first image for a given 
object when its NFC tag has been scanned. Thinking about how to display multiple 
images when a tag is scanned and whether to save all of them when a person collects 
an object will be the next focus of work https://github.com/aaronland/ios- 
wunderkammer/issues/20 since it coincides nicely with the code to display locally 


saved objects. 


In the first blog 
post https://www.aaronland.info/weblog/2020/06/16/revisiting/ about all 


of the work that has led to the wunderkammer application I wrote: 


The phrase "NFC tag" should be understood to mean "any equivalent 
technology". Everything I've described could be implemented using QR 
codes and camera-based applications. QR codes introduce their own 
aesthetic and design challenges given the limited space on museum wall 
labels but when weighed against the cost and complexity of deploying 
embedded NFC tags they might be a better choice for some museums. 


What I've been describing doesn't need to be done with NFC tags. It could also be 
done with QR codes, by photographing wall labels and using OCR software to 
extract accession numbers https://labs.cooperhewitt.org/2014/label- 
whisperer/ or even by using image detection algorithms to identify a given 
object https://www.sfmoma.org/read/team-selfie/ ina photo. All of these are 
just different ways of resolving a thing that a person is looking at to an identifier that 
can be found in a database so that it may be 


remembered https://www.aaronland. info/weblog/2020/04/06/futures/ 


SeuLcTURE IN THE Form 
OF 6 BANANA 


1@62-Ge-24 





Why is spelling so hard? I don't know what a "sculture" is either. My only excuse is 


that it was still early in the morning when I put this together and hadn't completely 
woken up yet. 


It's also really important to understand that I haven't done anything novel with NFC 
tags. Everything described in these blog posts has been possible to do with Android 
devices since 2014, before the Cooper Hewitt 


Pen https://aaronland.info/cooperhewitt/ even launched. 


In 2020 you can get a decent NFC-enabled Android phone for a hundred 

dollars https: //www.amazon.com/Nokia-2-2-Android-9-0-Pie/dp/B07SWFLKYW/ 
and probably less if you bought in volume. With a little bit of effort those devices 
could be configured to have a "kill switch" if and when they left the museum property, 
similar to one Apple uses to prevent theft in their 

stores https://arstechnica.com/gadgets/2020/06/local-authorities-will-be- 
alerted-iphone-looters-end-up-with-useless-phones/ . This would go a long 
way towards mitigating the need to ask visitors for their drivers license or credit card 
when handing out the devices. The lesson of both The 

O https://www.aaronland. info/weblog/2012/12/21/things/#futurenow at the 
Museum of Old and New Art http://www.mona.net.au/ and The 

Pen http://mw2015.museumsandtheweb.com/paper/strategies-against- 
architecture-interactive-media-and-transformative-technology-at-cooper- 
hewitt/ at Cooper Hewitt https://cooperhewitt.org/ is that if you want to 
ensure adoption for a given tool then you make it freely available without asking for 


anything in return. 
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Installation view of "A World of 
Characters: Advertising Icons from the 
Warren Dotz Collection" (SFO Museum) 
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Android devices even have public APIs for developers to use host card 

emulation https://en.wikipedia.org/wiki/Host_card_emulation (HCE) 
which allows the device to be programmed to act as though it were an NFC tag. This 
is widely understood to be how Apple Pay works, for example, but it is functionality 
only available to applications that Apple controls. HCE in a museum context offers a 
number of interesting opportunities. I probably wouldn't recommend installing a fleet 
of Android phones in the walls and gallery cases of a museum but, for a unit cost of 
100$, there are a number of places where a tiny computer with a screen, an internet 
connection, sophisiticated graphics and rendering capabilities and the ability to 
programatically broadcast itself (HCE) would be ripe with possibility. 


for bi | l (1943-2012) 





The story as I heard it was that, sometime before my arrival at Cooper Hewitt, the 
museum was working on an ad campaign with posters and stickers depicting an arrow 
and a word balloon that said "This is design". The idea was they would be placed all 
over New York City pointing at the kinds of things that people might not think were 
design. Things that people might not associate with a design museum. We thought 
about this a lot while we were bringing the Pen to 

life http://www. aaronland. info/weblog/2015/04/10/things/#mw2015 because, 
setting aside the reality of not being able to let people take the Pens home with them, 
those word balloons would have been an obvious place to put NFC tags. The thinking 
was that you could walk around the city and continue collecting things just like you 


did in the museum. 


I mention this because it's the first thing I thought of when Apple announced their 
upcoming App Clip https://developer.apple.com/app-clips/ technology last 
month. Here's an except from the description for the Explore App 

Clips https://developer.apple.com/videos/play/wwde2020/10174/ developer 


session: 


We'll explain how to design and build an app clip — a small part of your 
app that focuses on a specific task — and make it easily discoverable. 
Learn how to focus your app clip on short and fast interactions and 
identify contextually-relevant situations where you can surface it, like a 
search in Maps or at a real-world location through QR codes, NFC, or app 


clip codes. 


Essentially, App Clips are trimmed down applications that your phone downloads and 
runs, on-demand, when you scan a URL. The emphasis is on the "trimmed down" 
part. App Clips don't expose all the functionality of an application but rather select 
interactions. Most of the examples I've seen seem to involve making it easier for 
people to spend money but if you step back from that it's pretty easy to see how App 
Clips are basically the Pen: Scan a tag, save it your account, go back to whatever your 


were doing before. 


The phrase "applications that your phone downloads and runs, on-demand, when you 
scan a URL" should fill you with dread. It's a scenario that is primed for abuse. As 
such App Clips don't allow arbitrary URLs to invoke arbitrary applications. Both the 
App Clips and their URLs need to be registered with and delegated by Apple services 
and those URLs need to have a corresponding presence on the web that you also 
control: 
https://collection.cooperhewitt.org/objects/18458677/ 
instead of chsdm:0: 18458677. 


I have mixed feelings about App Clips, specifically the part where Apple acts as a 
gatekeeper for every interaction. There are legitimate security reasons for doing things 
this way but it smells like the kind of technological quicksand that is difficult or 
impossible to escape once you've taken the plunge. 





From the perspective of the wunderkammer application it means the only way a 
common wunderkammer style application, spanning multiple collections and 
institutions, would work with App Clips is if there was only a single wunderkammer 
application under the control of one individual or group. 


It would need to be a single organization that controlled a common wunderkammer 
domain and namespace, so either a large and often problematic consortium like 
ArtStor https://www.artstor.org/ or the for-profit client-services companies 
that pay for lunches and drinks at museum conferences. Sadly, there rarely seems to 
be anything in between those two options. 


In the original bring your own pen 
device https: //www.aaronland. info/weblog/2020/06/16/revisiting/#pen 


blog post I wrote: 


I built [the wunderkammer] application because I wanted to prove that it is 
within the means of cultural heritage institutions to do what we did with 


the Pen, at Cooper Hewitt, sector-wide. 


In the second everyone gets a 
wunderkammer! https: //www.aaronland. info/weblog/2020/07/07/action/ 


blog post I wrote: 


It is a tool I am building because it's a tool that I want and it helps me to 
prove, and disprove, some larger ideas about how the cultural heritage 
sector makes its collections available beyond "the museum visit" ... and 


offered to the cultural heritage sector in a spirit of generousity. 


At the same time I don't really believe that the cultural heritage sector will do 
anything with this work until it is repackaged and resold back to the sector as a "new" 
offering by a third-party vendor. It's pretty obvious that something which replicates 
the functionality of the Pen independent of its form is something that "museum 
customers" want. That's not a comment about the wunderkammer application 
specifically but about most of the things the sector tries to do by and for itself. That's 
also a big subject, full of nuance and complexity, so I will try to write about it more in 


future blog posts. 


Until then I will continue working to make the wunderkammer 
better https://github.com/aaronland/ios-wunderkammer one tiny feature at a 


time. 


2020-07-13 
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just how easy 


just how easy 





In the bring your own pen 
device https://www.aaronland. info/weblog/2020/06/16/revisiting/#pen 


blog post I wrote that: 


..the ability to scan arbitrary NFC tags in iOS devices was a holy grail in 
museum circles, always just around the corner but never actually 


possible. 


The other holy grail, in museum circles, has been e-ink displays. Specifically the 
ability to craft and fashion low-cost and muted screens for public display in in the 
galleries as wall labels or as signage throughout the building. In 2013 you could find 
Amazon Kindles https: //en.wikipedia.org/wiki/Amazon Kindle that had 
been repurposed as little advertising billboards in some restaurants in New York 


City so the thinking went: If a restaurant can do this why can't a museum? 


At the time there were maybe a handful of vendors who might build these kinds of 
displays but they were surprisingly expensive. When compared to the cost of a 
Kindle they seemed shockingly expensive, even if that shock betrayed a lack of 


understanding about the manufacturing process and the scale of the effort and 


investment required to produce the Kindle. The issue of cost was compounded by a 
need to be able to update these screens automatically over the network, which again 
only serves to underline how much work Amazon did to deliver text over cellular 
networks to cheap, low-powered and, importantly, really thin computers. Even if 
you could solve the computing problem no one seemed to be producing e-ink 
displays much larger than index cards for anyone except Amazon. 


If it's just a kindle on the wall 





MCN 2014: It's Bigger on the Inside: Adventures in Time, Space, and the 3rd Dimension 


If you haven't already seen Miriam Langer and Stanley Cohen's presentation at 
MCN 2014 https: //www.youtube.com/watch?v=3vLYEqNy9wU about their effort 
to develop an open-source, networked and museum-specific e-ink display to do all 
these things then you should watch it now. It starts at about the 34 minute 

mark https://www. youtube.com/watch?v=3vLYEqNy9wU and is an excellent 
presentation about, in their words, "just how easy it was not to do" at the time. Go 
ahead, I'll wait. 


Fast forward to the end of 2018 and Bryan Boyer's blog post titled Creating a Very 
Slow Movie Player https://medium.com/s/story/very-slow-movie-player- 


499£76c48b62 


Very Slow Movie Player (VSMP) is an object that contains a Raspberry 
Pi computer, custom software, and a reflective ePaper display (similar to 
a Kindle), all housed in a 3D-printed case. Every two-and-a-half 
minutes, a frame from a film that’s stored on the computer’s memory 
card is extracted, converted to black and white using a dithering 
algorithm, and then communicated to the ePaper display. The video 
below explains the process, but essentially, the film is played at a rate of 
24 frames per hour in contrast to the traditional 24 frames per second. 


That’s the slow part, obviously. 


Bryan's write-up about the rationale and development process for building VSMP is 
very good so if you haven't read that either yet you should go read it 
now https://medium.com/s/story/very-slow-movie-player-499f76c48b62 


T'll wait. 


Three things stuck out to me when I read Bryan's post. First, was that 7.5 inch e-ink 
displays had started to become available for retail purchase at affordable prices. 
Second, that they worked with plain vanilla Raspberry Pi computers and had high- 
level programming interfaces for updating the screens. Third, the wiring necessary 


to connect the display to the Raspberry Pi seemed refreshingly simple. 


I walked around with Bryan's post in my head until a few months ago when I 
decided to see how hard it would be build my own VSMP or something like it. This 
was meant to be a "mornings and weekends" project but the thinking was that if I 
could get something running for myself, during the margins of the day, then perhaps 
it could be repurposed for use in the cultural heritage sector. Perhaps the thing that 
Miriam https://mobile.twitter.com/arduinogirl and Stanley were trying to 


build in 2014 was now within our reach. 





It is. There are still some rough edges but it can be done, not accounting for volume 
purchasing, for about 70$ a unit on the low end, 100$ on the high end and 80$ in 
between. 


Waveshare produces a 800x480 pixel 7.5inch e-ink 

display https://www.waveshare.com/7.5 inch-e-paper-hat.htm _ that retails 
for about 65$ on Amazon https://www.amazon.com/waveshare-7-5inch-HAT- 
Raspberry-Consumption/dp/B075R40yY3L_ . Importantly the display conforms to the 
Raspberry Pi HAT 

specification https://www.raspberrypi.org/blog/introducing-raspberry-pi- 
hats/ which means that it can simply be "plugged in" to a Raspberry Pi computer. 
It's hard to overstate how important this is. Maybe it shouldn't be but from an 
operations perspective, in a museum, not having to muck about with about with 


wires and soldering reduces the complexity of things by an order of magnitude. 


The Raspberry Pi itself could be as expensive as 35$ a 

unit https://www.raspberrypi.org/products/ if you need to do a lot of 
computing but it could also be as cheap as 5$ a unit for a low-powered Raspberry 
Pi Zero https://www.adafruit.com/product/2885 .The Zero ships without any 


network interfaces (ethernet or WiFi) and requires that you solder on the connectors 


for the display HAT to plug in to but for 14$ you can buy a Raspberry Pi Zero 
HW nhttps://www.adafruit.com/product/3708 which comes with a pre- 
soldered connector and both WiFi and Bluetooth chips. Whether or not the extra 9$ 
is worth it is not for this blog post to decide. 





To put that in some perspective Waveshare also sells a 10.3 inch HDMI-enabled e- 
ink display https: //www.waveshare.com/eink-disp-103.htm for 539$. It 
comes in an elegant enclosure with a bunch of different connectors but that's still 
539$ without an actual computer to manage what the screen is doing. 


I mentioned that e-ink displays have begun to ship with high-level interfaces, 
usually written in Python, for manipulating the screen. For example, here's how you 
would open an image file and render it on a Waveshare display using the Python 
libraries they provide https://github.com/waveshare/e-Paper 


from waveshare_epd import epd7in5_v2 
from PIL import Image 

fh 
im 


open("/path/to/image.jpg", "r") 
Image.open(fh) 


epd = epd7in5_V2.EPD() 
epd.init() 


epd.display(epd.getbuffer(im) ) 


That's it. 


It is the combination of pluggable hardware and high-level expressive programming 
languages for operating that hardware and being able to do so in a traditional Unix 
operating system that makes all of this exciting. It means that the code and the 
hardware above is, effectively, the common platform that any museum or cultural 


heritage institution can use to deploy e-ink displays. 


Where /path/to/image. jpg comes from and how often it gets updated are 
details that will vary from institution to institution. Those images might come out of 
a centralized content-management system or be generated dynamically on the 
device. They might be delivered over the network or retrieved out of a local cache 
on disk. The advantage of a full-fledged Unix operating system rather than a smaller, 
trimmed down programming environment is that they make developing for these 
bespoke scenarios easier and faster and the place where those custom tools intersect 
with the screen is a simple image. The screen itself doesn't need to know, or care, 


where an image comes from. 


Here's an object from the SFO 


Museum https://millsfield.sfomuseum.org/collection/ collection: 





I mentioned that there are still some rough edges to all of this. Power is an obvious 
concern. A Raspberry Pi, even a Pi Zero not doing anything except replacing an 
image every hour, will drain a standard USB battery inside of a day. The 
consequence of that is that when installing one of these displays you'll need to factor 
in and account for, and possibly hide, a micro-USB cable running back to a power 
source. 


The other noticeable rough edge is that the refresh rate on the Waveshare screen is, 
well, noticeable. I haven't spent any time yet investigating whether this can be 
remedied with code or hardware so the rule of thumb might just be: Don't update the 
screen very often or when a lot of people might be looking at it. 


Here's a video showing what the refresh rate between images looks like: 


Ra 
“sy 





Finally, this is all very much a work in progress so there are no simple or easy 
"installer" tools. I've been keeping notes and tools to display random images, on a 
timer, from a local "wunderkammer" database in a py-wunderkammer- 
waveshare https://github.com/aaronland/py-wunderkammer-waveshare 
repository. The screen that I am building is meant to run entirely offline so all the 
images are bundled as base64-encoded data URLs, as described in the so that it 
may be 

remembered https: //www.aaronland.info/weblog/2020/07/13/experience/#r 


emembered blog post. 


The tools for generating these "Wunderkammer" style databases have also been 


separated in to discrete packages. They are: 


e go-wunderkammer https: //github.com/aaronland/go- 


wunderkammer , which contains tools for producing database from a 
stream of line-separated OEmbed (JSON) records. 


e go-wunderkammer-image https://github.com/aaronland/go- 
wunderkammer-image , which contains tools for appending a base-64 


encoded image to a stream of line-separated OEmbed (JSON) record. 


© go-wunderkammer-www_ https://github.com/aaronland/go- 
wunderkammer-www , which contains tools for viewing the contents of a 


database produced by go-wunderkammer. 


Here's an example of how it all fits together producing an offline-enabled 
"wunderkammer" database of objects from the Hirshhorn Museum and Sculture 
Garden https://hirshhorn.si.edu/ collection, where each image is retrieved 
from the Smithsonian servers and 

dithered https://en.wikipedia.org/wiki/Dithering for better rendering on 


an e-ink display: 


$> sqlite3 /usr/local/go-wunderkammer/hmsg.db < /usr/local/go-wunderkammer/schema/sqlite/oembed.sql 
$> /usr/local/go-smithsonian-openaccess/bin/emit \ 

-oembed \ 

-bucket-uri file:///usr/local/OpenAccess metadata/objects/HMSG \ 


| /usr/local/go-wunderkammer-image/bin/append-dataurl \ 
-dither \ 


/usr/local/go-wunderkammer/bin/wunderkammer-db \ 
g 
-database-dsn 'sql://sqlite3/usr/local/go-wunderkammer/hmsg.db' 


In addition to the go-wunderkammer tools this example uses the go- 
smithsonian-openaccess's emit tool https://github.com/aaronland/go- 
smithsonian-openaccess described in the everyone gets a 

wunderkammer! https: //www.aaronland. info/weblog/2020/07/07/action/#wu 
nderkammer blog post. There is also a similar tool in the go-metmuseum- 
openacess https://github.com/aaronland/go-metmuseum-openaccess package 
for working with the Metropolitan Museum of Art's Open Access 


Initiative https://github.com/metmuseum/openaccess data. 


And here's what the result of that example looks like. In this photo the e-ink display 
HAT has been plugged in to a Raspberry Pi Zero which isn't visible since it's the 
same size as the HAT iself. The pencil is included for scale. The total height of the 
Pi Zero and the display HAT stacked together is about 1.5 inches. 





The device isn't powered on in this photo but since it's an e-ink display it doesn't 
need power to keep showing the last image that was rendered to the screen. 


In addition to dithering images the append-dataur1 tool has the ability to do 
content-aware resizing (or seam 


carving https://inst.eecs.berkeley.edu/~cs194-26/fa1l6/hw/proj4- 
seamcarving/imret.pdf ) using Endre Simo's 

caire https://github.com/esimov/caire library. Content-aware resizing can be 
useful if you want an image to fill all the available screenspace without cropping the 


image. The results are still mixed. 


For example, this is probably an acceptable resizing given that the photo was 
actually shot in portrait mode: 





Whereas this is probably not: 





And this is just weird and a little scary, with apologies to the National Air and 
Space Museum https://airandspace.si.edu/ (NASM) collection: 





Speaking of NASM, I also created a "wunderkammer" style database of their 
collection like the one I created for the Hirshhorn but without image dithering and 


used it to run an instance of the wunderkammer-server tool, like this: 


$> sqlite3 /usr/local/go-wunderkammer/nasm.db < /usr/local/go-wunderkammer/schema/sqlite/oembed.sql 
$> /usr/local/go-smithsonian-openaccess/bin/emit \ 

-oembed \ 

-bucket-uri file:///usr/local/OpenAccess metadata/objects/NASM \ 


| /usr/local/go-wunderkammer-image/bin/append-dataurl \ 
-format gif \ 


| /usr/local/go-wunderkammer/bin/wunderkammer-db \ 
-database-dsn 'sql://sqlite3/usr/local/go-wunderkammer/nasm.db' 


...time passes 


$> /usr/local/go-wunderkammer-www/bin/wunderkammer-server \ 
-database-dsn 'sql://sqlite3/usr/local/go-wunderkammer/nasm.db' 


Then, for example, if I visit http: //localhost:8080/object? 
url=si://nasm/o/A19480187000 ina web browser I see this: 


wunderkammer *” 





Roberts 4X, In-line 4 Engine (Gift of Harry H. Ford.) 
National Air and Space Museum 


* https://airandspace.si.edu/collection/id/nasm_A19480187000 
‘= https://ids.si.edu/ids/download?id=NASM-A19480187000-NASM2018-10846 screen 
« siyvinasm/o/A19480187000 





Roberts 4X; In-line 4 Engine (Gift of Harry H. Ford.) 
National Air and Space Museum 


«* https://airandspace.si.edu/collection/id/nasm_A18480187000 
+ https://ids.si.edu/ids/download?id=NASM-A19480187000-NASM2018-10844_screen 
* siy/nasm/o/A19480187000 


There are actually four images for this object but I've trimmed the screenshot. As 
with the e-ink display example all of the images are being served locally from the 
"wunderkammer" database having been retrieved from the Smithsonian image 


servers by the append-dataurl tool. 


The wunderkammer-server tool has the ability to show individual images as 
well as all the images for a given object. The tool is currently lacking pagination 
which will happen shorty https://github.com/aaronland/go-wunderkammer- 
www/issues/1 since since some collections have may have dozens of images for a 
single object. It also comes with a handy random button for general spelunking. 
There's more to write about the wunderkammer-server tool but I'll save that for 
another post. 


Today, let's just enjoy the knowledge that e-ink displays aren't as hard as they used 
to be. 
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broadcast nation 


to good effect 


to good effect 


Towards the end of the so that it may be 
remembered https://www.aaronland. info/weblog/2020/07/13/experience/#reme 


mbered blog post I wrote: 


Android devices even have public APIs for developers to use host card 
emulation (HCE) which allows the device to be programmed to act as 
though it were an NFC tag. This is widely understood to be how Apple Pay 
works, for example, but it is functionality only available to applications that 
Apple controls. HCE in a museum context offers a number of interesting 
opportunities. I probably wouldn't recommend installing a fleet of Android 
phones in the walls and gallery cases of a museum but, for a unit cost of 
100$, there are a number of places where a tiny computer with a screen, an 
internet connection, sophisiticated graphics and rendering capabilities and 
the ability to programatically broadcast itself (HCE) would be ripe with 
possibility. 


In both the bring your own pen 

device https://www.aaronland. info/weblog/2020/06/16/revisiting/#pen and 
so that it may be 

remembered https://www.aaronland. info/weblog/2020/07/13/experience/#reme 


mbered blog posts I also wrote: 


The phrase "NFC tag" should be understood to mean "any equivalent 
technology". Everything I've described could be implemented using QR 
codes and camera-based applications. QR codes introduce their own 
aesthetic and design challenges given the limited space on museum wall 
labels but when weighed against the cost and complexity of deploying 
embedded NFC tags they might be a better choice for some museums. 


Take SFO Museum https://sfomuseum.org/ , for example, where most of the wall 
labels are mounted on slanted plates behind glass. Reading NFC tags can be tricky 
even when you can touch them. NFC tags that are six to ten centimeters away behind 
glass and positioned at an angle from that glass are basically invisible to an NFC 


reader. 





Installation view of "Before the 21st Century: An Ode to Boats, Cars, 
Motorcycles, Planes, and Trains", SFO Museum. 


After those three blog posts I wrote about working with e-ink displays and Raspberry 
Pi computers. In that blog post, titled just how 
easy https: //www.aaronland. info/weblog/2020/07/20/dots/#easy ,I said: 


The Raspberry Pi Zero ships without any network interfaces (ethernet or 
WiFi) and requires that you solder on the connectors for the (e-ink) display 
HAT to plug in to but for 14$ you can buy a Raspberry Pi Zero HW which 
comes with a pre-soldered connector and both WiFi and Bluetooth chips. 


There is also the Raspberry Pi Zero 

W https://www.raspberrypi.org/products/raspberry-pi-zero-w/ which is the 
same as a the HW but without a pre-soldered connector. It retails for 10$ What I didn't 
say in that blog post but what I've been thinking about for a little while now is: What if 
the ID of each object was broadcast as a Bluetooth Low Energy (BLE) advertisement 
as it was being displayed? 


This isn't a new idea. It's what Bluetooth 
"beacons" https://en.wikipedia.org/wiki/Bluetooth_low energy beacon are 


designed to do. By and large, I have not been a huge fan of either Bluetooth or beacons 


in a museum setting. Bluetooth is a complicated technology that is made more difficult 
by the complexities of working with radio frequencies in uncontrolled environments. 
Bluetooth opens the door to whole universe of security concerns. Bluetooth beacons 
have, so far, been notoriously expensive and challenging to program, update and 


maintain. 





photograph: Pan American Airways, radio operators. Photograph. Gift of Jon E. 
Krupnick, SFO Museum Collection. 2008.056.1115. 


It is possible to use beacons to good 

effect https://www.nytimes.com/2016/11/21/arts/design/the-natural-history- 
museum-has-a-new-app.html but never without a dedicated, costly and concerted 
long-term effort. Matt Tarr's Location, location, location! The proliferation of 
indoor positioning and what it means and doesn’t mean for 

museums https://mw2015.museumsandtheweb.com/paper/location-location- 
location-the-proliferation-of-indoor-positioning-and-what-it-means-and- 
doesnt-mean-for-museums/ paper about the American Museum of Natural 
History https://www.amnh.org/ 's (AMNH) Explorer application and Shelley 
Bernstein's The Realities of Installing iBeacon to 

Scale https: //www.brooklynmuseum. org/community/blogosphere/2015/02/04/the 
-realities-of-installing-ibeacon-to-scale/ blog post about the experience at 


Brooklyn Museum https://www.brooklynmuseum.org/ are good discussions of 


the benefits and the challenges of deploying Bluetooth beacons in a museum. 


The cost to develop AMNH's Explorer 

application https://www.amnh.org/apps/explorer , inclusive of the 800 beacons 
installed in the museum and the native mobile applications that were built to use them, 
is said to have been "about $2.75 million". As a practical matter this makes it an 


approach far outside the reach of most museums or cultural heritage organizations. 


In the just how 
easy https://www.aaronland.info/weblog/2020/07/20/dots/#easy blog post, 


writing about the use of Raspberry Pi computers, I said: 


It is the combination of pluggable (low-cost) hardware and high-level 
expressive programming languages for operating that hardware and being 
able to do so in a traditional Unix operating system that makes all of this 


exciting. 


The Raspberry Pi Zero W https: //www.raspberrypi.org/products/raspberry- 
pi-zero-w/ isa 10$ computer with a 1GHz CPU, 512MB of RAM with the ability to 
connect to the internet over Wifi, the ability to communicate over Bluetooth and 
broadcast over Bluetooth Low Energy (BLE) that runs a modern (and updated) Unix 
operating system with support for most programming languages in use today. The 
principal drawback, compared to commercial BLE beacons, is that they require a 
power source which means that what might have begun as a technology problem is also 


very much an operations and a physical architecture problem. 


Being a general purpose 

computer https://boingboing.net/2012/01/10/lockdown.html the Zero doesn't 
come with any default tooling for configuring itself as a BLE beacon so developing that 
software becomes an additional burden. Greg Turner's An Internet-of-Things strategy 
for ACMI https://labs.acmi.net.au/an-internet-of-things-strategy-for- 
acmi-4e7£717009a9 blog post about how they are maintinaing a fleet of 800-1000 
Raspberry Pi computers that have been installed in the galleries at the Australian 
Centre for the Moving Image https://www.acmi.net.au/ is a good example of 


how the configuration challenge can be managed. 


There are tradeoffs with any technology choice and they are influenced by the 
circumstances in each institution. As much as I might like to install NFC tags in all the 
gallery spaces at SFO Museum the choices that were made to meet the demands of 
exhibiting objects in a busy airport make NFC tags impractical. Could AMNH install 
800 Raspberry Pi Zero W computers in discrete locations throughout their galleries in a 
way that visitors wouldn't see them? Perhaps but it's easy to imagine scenarios where 
that would be difficult or impossible. 


One advantage that standalone and battery powered BLE beacons have is that they can 
be easily moved to another location. In order to do the same with a Raspberry Pi and 
institution would need to also design and build a modular approach for running dozens 
of power sources to different locations both on the floor and in the walls in any given 
gallery. That's not something most museums can do, easily, right now. This difficulty 
suggests it is something that any museum looking to do renovations should make a 


priority. 
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Figure 2.1: Undirected advertising 


> 8 Synchronization 
State 





I haven't been successful in programming a Raspberry Pi Zero to act as a BLE beacon 
yet. I am confident it's possible and the documentation appears to be meticulous and 
detailed; the official Bluetooth 4.0 


specification https: //www.bluetooth.com/specifications/bluetooth-core- 
specification/ is 3,256 pages long, not including subsequent addenda. Perversely, 
that specificity absent any simple "I just want to..." cookbook-style examples serves as 


a barrier for what is still a mornings-and-weekends project. 


So far I have been dependent on other people's software implementations of the 
Bluetooth specification and I have only been able to make one of three packages, 
Paypal's gatt https://github.com/paypal/gatt library written in Go, actually 
broadcast anything. Unfortunately while gatt is able to broadcast messages that can 
be seen by an iOS device that device doesn't think the messages contain any data. The 
gatt codebase hasn't been updated in five years so it is unclear whether the problem is 
that it doesn't conform to the current Bluetooth specification or something else. Maybe 
when I've had a chance to read the 400 pages outlining the "Low Energy Controller" in 


the documentation I will better understand what's going on. 


In the interest of testing my original idea — What if the ID of each object was 
broadcast as a Bluetooth Low Energy (BLE) advertisement as it was being displayed? 
— lopted instead to teach the wunderkammer 

application https://github.com/aaronland/ios-wunderkammer _, first described in 
the bring your own pen 

device https: //www.aaronland.info/weblog/2020/06/16/revisiting/#pen blog 


post, not only to scan for BLE advertisements but to broadcast them as well. 


Here are some screenshots and a video to demonstrate what that looks like: 
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There are now two "broadcast" buttons in the wuanderkammer navigation bar. The 
original antenna. radiowaves.left.and.right icon used to scan NFC tags 
is now used to start and stop BLE advertising (broadcasting) in the application. The 
tag-scanning activity is now represented by the 
badge.plus.radiowaves.right icon which has been flipped horizontally to 
better signal the idea that scanning happens outside the device. In this screenshot the 
broadcasting button is disabled because the device's Bluetooth functionality has been 
turned off. 
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This is what things look like when Bluetooth is enabled. If a device hasn't enabled 
Bluetooth or doesn't support scanning NFC tags both buttons would be disabled. 
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Print (Harris Brisbane Dick Fund, 
1922) (Metropolitan Museum of Art) 
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When the "broadcasting" button is pressed it turns red to signal that it is advertising the 
object ID that the wanderkammer application is displaying. 
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Choose Option 


NFC 


Bluetooth 


Cancel 


The scan button has been updated to present a modal dialog when the device is able 
to scan for object tags using different technologies. 


Here's a video of two iOS devices, each with a copy of the wunderkammer 
application, where the device on the left is broadcasting BLE advertisements of the 
object it is showing and the device on the right is "scanning" for those advertisements 
and using the data contained in them to show the same object. 





As with NFC tags the device on the left is broadcasting an object ID like 
sfom: //id/12345 and the device on the right is resolving that identifier in to a 
fully qualified URL that it can use to retrieve an object image and metadata from the 


internet or a local database. 


Unlike NFC tags the device on the left updates the data it is broadcasting (the object 
identifier) when the object it is displaying changes and the device on the right continues 
to listen for those updates. This feels like a significantly different and novel interaction 
model, from what's currently available to visitors, that it could be used to good effect in 


a museum setting. 


In both cases, encoding data in NFC tags or broadcasting it as BLE advertisements, 
there still needs to be an application that consumes the data and does something with it. 
Development and maintenance costs, as well as the awareness and adoption, of 
bespoke applications to work with these signals continue to be challenges that the 
cultural heritage sector struggles with. 


Shelley Bernstein's Building is easy, but launching is 

hard https://www.brooklynmuseum.org/community/blogosphere/2015/07/22/buil 
ding-is-easy-but-launching-is-hard/ and Sara Devine's Messaging is 

Harder https://www.brooklynmuseum. org/community/blogosphere/2015/08/06/m 
essaging-is-harder/ blog posts about raising awareness, adoption and use of the 
Ask Brooklyn https://www.brooklynmuseum.org/ask mobile device at Brooklyn 
Museum illustrate the problems well. It's generally worth reading anything on the 
Brooklyn Museum tech 


blog https: //www.brooklynmuseum.org/community/blogosphere/ but especially 
any post written about the Ask Brooklyn 

initiative https: //www.brooklynmuseum.org/community/blogosphere/tag/askbkm 
/ 


There is also Seb Chan and Luke Dearnley's 2012 Museums and the Web (MW) paper 
Using QR codes, mobile apps and wifi tracking data to understand visitor 
behaviour in 

exhibitions https: //www.museumsandtheweb.com/mw2012/programs/using qr code 


s_mobile apps_and_wifi_tracking.html about the difficulties, and ultimately 





failure, of getting visitors to download an application once they've set foot in the 
museum. So far I have only been able to find a placeholder for the paper on the MW 
website but not the actual content of the paper itself. Maybe when 

Seb https://sebchan.substack.com/?no_cover=true OF 

Luke https://mobile.twitter.com/lukesnarl have a chance to read this they can 


point me to the paper or their slides. 


I don't have a simple answer to these problems but earlier this year in the Geotagging 
Photos at SFO Museum, Part 1 — Setting the 
Stage https://millsfield.sfomuseum.org/blog/2020/04/23/geotagging/ blog 


post I wrote: 


The larger motivation for doing things this way is to ... address an evergreen 
subject in the cultural heritage sector: The lack of common software tools, 
and the challenges of integrating and maintaining those infrastructures, 


across multiple institutions. 


My own feeling is that many past efforts have failed because they tried to do 
too much. It’s a bit of a simplification but a helpful way to think about these 


tools is to imagine they consist of three steps: 


e Data comes from somewhere. For example, an image comes out of a 
database and an asset management system. 


e Something happens to that data. For example, an image is geotagged. 


e The data then goes somewhere else. For example, the geotagging data 
goes in to a database. 


The problem with many tools, developed by and for the sector, has been that 
they spend a lot of time and effort to abstract the first and the last points and 
ultimately fail. The nuances, details and limitations, not to mention the vast 
inequalities, in all the different technical infrastructures within the cultural 
heritage sector are legion. Developing an abstraction layer for the retrieval 
and publishing of cultural heritage materials that attempts to integrate and 
interface directly with an institution’s technical scaffolding is going to be a 


challenge at best and a fool’s errand at worst. 


The cultural heritage sector needs as many ... small, focused, tools as it can 
produce. It needs them in the long-term to finally reach the goal of a 
common infrastructure that can be employed sector-wide. It needs them in 
the short-term to develop the skill and the practice required to make those 
tools successful. We need to learn how to scope the purpose of and our 
expectations of any single tool so that we can be generous of, and learn 


from, the inevitable missteps and false starts that will occur along the way. 


I mention that for two reasons. 


The first is to argue that confusing the value of making the objects in our collections 
addressable, by publishing stable and permanent identifiers be they on wall labels, NFC 
tags or BLE advertisements, with the difficulties of building, maintaining and 
promoting a museum's own application of that data is a mistake. To me the purpose of 


broadcasting an object's identifier, of announcing its presence on and participation with 


the internet, is to foster as many applications of that data as possible. 


That does not, and should not, preclude an institution from having its own application 
and editorial viewpoint around these objects but nor should the success or failure of 
those endeavours be the measure by which the value of making our collections 
accessible in the first place is gauged. The effort to do these things is, I believe, worth it 
on its merits alone. The day-to-day work becomes ensuring that these efforts are done 
in a way, both technically and financially, that they outlast people's initial 

reluctance https://www.aaronland. info/weblog/2020/04/06/futures/#mw20 to 


embrace them. 


eee wunderkammer 


(yo 
print("central.state is -unknown") 
case resetting: 
’ print("central.stote is .resetting") 
self.ble_available = false 
case .unsupported: 
entral.stete is .unsupported") 





2020-07-27 14311: 29.946995-070@ wunderkanmer|4e41:73703) Metal 

2020-07-27 14:11:3@.183991-870@ wunderkammer[4941:73783] [CoreN 
areFeaturesSupported:outérror:]:156 PC Error: Error Domai 
service on pid @ named com.apple.nfcd.service.corenfc was i 
UserInfo={NSDebugDescription=The connection to service on p 
invalidated from this process.} 

2020-07-27 14:11:30.386449-0700 wunderkammer[4841:73783] [CoreN 
areFeaturesSupported:out€rror:]:156 XPC Error: Error Domai 
service on pid @ named com.apple.nfed.serviee.corenfe was i 
UserInfo={NSDebugDescription=The connection to service on p 
invalidated fron this process.) 

2020-07-27 14:11:30. 688885-0700 wunderkammer[4841:73703] [CoreN 
areFeaturesSupported:out€rror:]:156 XPC Error: Error Domai 
service on pid @ named com.apple.nfed.service.corenfe was i 
UserInfo={NSDebugDescription=The connection to service on p 
invalidated from this process.} 

2020-07-27 14:11:31.091136-0700 wunderkammer[4041:73703] [CoreN 
areFeaturesSupported:outérror:]:156 XC Error: Error Domai 
service on pid @ named com.apple.nfcd.service.corenfe was i 
connection to service on pid @ naned con.apple.nfcd.service rT ° ae 

central state ds on Installation view of "Celebrating a Vision: Art & 

35-0780 debug: Scan tag caeeparaests 
; Start BLE scanning Disability" (SFO Museum) 
: Try to retrieve peripheral 5066 

: Found peripheral, reconnecting. 

: Stop BLE scanning 

? Connecting to ‘wunderkasmer* (oe) ah oo 

: Connected to ‘wunderkanmer' 

= Received BLE message ‘sfon: | eps 


: Process message sfom://0/1159341547 

























11:37-8788 debug: Object 1D 1159941547 resolves as 

/mil1sfield.sfonuseun.org/objects/1159341547 

'14:11:37-0700 debug: Ofnbed URL resolves a5 

foenbed?url=htt ps'3AN2FX2Fmi 11 sfield. sfonuseun.org'2Fobjectsk2F1159341547 
:11:41-0780 debug: Received BLE message 'sfon://o/1159341595' 

2020-87-27714:11:41-0780 debug: Process message stom://0/1159341595 


The second reason is to solicit help in building, documenting and distributing the 
simplest and dumbest tool to make broadcasting an object identifier as a BLE 
advertisement on a Raspberry Pi computer possible. "Version 1" could be as simple as 
a command-line tool that only accepts a single parameter, the object identifier to 


broadcast. For example: 


$> ble-tool sfom://id/6789 


It could be as complicated as: 


$> ble-tool -service-id {CUSTOM_BLE_SERVICE} -characteristic-id {CUSTOM_BLE_CHARACTERISTIC} sfom://id/( 


The Bluetooth specification is over 3,000 pages long and outlines a symphony of 
functionality and possible uses none of which are necessary for this tool. "Version 2" of 
my imagined tool should allow the object identifier to be updated dynamically, to 
stream notifications to a consuming device like I demonstrated in the video, but after 


that I don't think it needs to do anything else. By design. 


This is what I mean when I talk about "small, focused tools". The details of why or 
where object identifiers might be broadcast as BLE notifications will vary and those 
details should be left to individual institutions. The commonality in those applications 
is the act of broadcasting and those are the tools and tasks that we should make as 


simple and inexpensive as possible. 


UNITED 





photograph: San Francisco International Airport (SFO), United Airlines. 
Photograph. Transfer, SFO Museum Collection. 2011.068.120. 


It should not be a requirement to have to use a vendor specific device in order to do 
these things. I built this functionality in to the wuanderkammer application because 
Apple made it easier to get things working than doing the same on a Raspberry Pi. In 
the end it wasn't even "easy" but it was still easier than the alternative. As a sector we 
should endeavour to fix that disparity. There are good reasons why deploying iOS 
devices in to a production setting makes sense but we will all benefit from being able to 


do the same with a 10$ Raspberry Pi computer. 


I will keep working on this problem because I want it to integrate it with the 
wunderkammer-server tool I mentioned at the end of the just how 

easy https://www.aaronland.info/weblog/2020/07/20/dots/#easy blog post but 
I would welcome some help. In the meantime I have merged all the Bluetooth-specific 
code in to the main branch of the ios- 

wunderkammer https://github.com/aaronland/ios-wunderkammer application 
if anyone is curious to see how it can be done https: //github.com/aaronland/ios- 


wunderkammer/blob/master/wunderkammer/ViewController.swift in iOS devices. 
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Small focused tools 


Small focused tools 





negative: San Francisco International Airport (SFO), landscape 
maintenance. Negative. Transfer, SFO Museum Collection. 
2011.032.2415. 


This was originally published on the SFO Museum Mills Field 
weblog https://millsfield.sfomuseum.org/blog/2020/08/04/ 


small-tools/ ,in August 2020. 


It's been a little while since I've written anything here. | still need to 


finish the series of posts we started about our work geotagging 
photos in the SFO Museum 

collection https://millsfield.sfomuseum.org/blog/tags/geot 
agging and this will happen soon. As a prelude to that wrap up I 
want to touch on something I said in the Geotagging Photos at 
SFO Museum, Part 1 — Setting the 

Stage https://millsfield.sfomuseum. org/blog/2020/04/23/g 


eotagging/ blog post: 


The cultural heritage sector needs as many small, 
focused tools as it can produce. It needs them in the 
long-term to finally reach the goal of a common 
infrastructure that can be employed sector-wide. It 
needs them in the short-term to develop the skill and 
the practice required to make those tools successful. 
We need to learn how to scope the purpose of and 
our expectations of any single tool so that we can be 
generous of, and learn from, the inevitable missteps 


and false starts that will occur along the way. 


In that spirit this blog post is about four small command-line 
utilities we've written to help us do our work and are sharing with 
the wider cultural heritage sector. These tools aren't specific to SFO 


Museum and might be useful to other organizations in the sector. 


dump and restore (from Elasticsearch) 





negative: San Francisco International Airport (SFO), runway or taxiway construction. Negative. Transfer, SFO 
Museum Collection. 2011 .032.1283. 


Recently we needed to migrate 11 million records from one 
Elasticsearch https://www.elastic.co/guide/en/elasticsear 
ch/reference/current/elasticsearch-intro.html instance to 
another. Elasticsearch has its own process for creating and 
restoring 

snapshots https://www.elastic.co/guide/en/elasticsearch/r 


eference/current/snapshot-restore.html of an index but it is 


sufficiently complex and time-consuming that I decided to write my 


own tools to perform the migration instead. 


The first tool, called dump, exports all the records in an 
Elasticsearch index as a stream of line-separated 

JSON https://en.wikipedia.org/wiki/JSON streaming 
records that can be written to a file. The second tool, called 
restore, reads a file containing line-separated JSON records and 
inserts them in to an Elasticsearch index. Both tools are written in 
the Go programming language https://golang.org which 
allows them to be compiled and distributed as standalone binary 


applications with no external dependencies. 


By default the dump tool outputs everything to 

STDOUT https://en.wikipedia.org/wiki/Standard streams# 
Standard output_(stdout which means you can 

pipe https://en.wikipedia.org/wiki/Pipeline (Unix the 
data in to other tools like 

bzip2 https://en.wikipedia.org/wiki/Bzip2 to compress it 


before writing everything to a file on disk. For example: 


$> bin/dump \ 
-elasticsearch-endpoint http://localhost:9200 \ 
-elasticsearch-index millsfield \ 


| bzip2 -c > /usr/local/data/millsfield.bz2 


2020/07/09 13:29:52 Wrote 1000 (55658) records 
2020/07/09 13:29:53 Wrote 2000 (55658) records 


2020/07/09 13:30:28 Wrote 53000 (55658) records 
2020/07/09 13:30:29 Wrote 54000 (55658) records 
2020/07/09 13:30:29 Wrote 55000 (55658) records 
2020/07/09 13:30:29 Wrote 55658 (55658) records 


As of this writing the Go programming language doesn't have 


native support for bzip2 

encoding https://github.com/golang/go/issues/4828 . That's 
why we need to pipe the output of the dump tool to the bzip2 
utility. Go does have support for decoding bzip2-encoded files so 
the restore tool can read the file we just exported by setting the 


is-bzip flag. For example: 


$> ./bin/restore \ 
-elasticsearch-endpoint http://localhost:9200 \ 
-elasticsearch-index millsfield \ 
-is-bzip \ 
/usr/local/data/millsfield.bz2 


"NumAdded": 55658, 
"“NumFlushed": 55658, 
"NumFailed": 0, 
"“NumIndexed": 55658, 
"“NumCreated": 0, 
"NumUpdated": 0, 
"NumDeleted": 0, 
"NumRequests": 31 


The restore tool is also able to read data from 

STDIN https://en.wikipedia.org/wiki/Standard streams#St 
andard input (stdin so if we wanted to we could pipe the 
output of the dump tool directly in to the restore tool, migrating 
one Elasticsearch index to another without the need to write any 


files to disk. For example: 


$> bin/dump \ 
-elasticsearch-endpoint http://localhost:9200 \ 
-elasticsearch-index index-1 \ 
| bin/restore \ 
-elasticsearch-endpoint http://localhost:9200 \ 
-elasticsearch-index index-2 \ 
That's all these tools do but we think they are useful (and save time) 
all the same. In the end they made our Elasticsearch migration 
faster than the official snapshot-and-restore model. As an added 


bonus, the exports themselves are in an easy-to-read and easy-to- 


parse format that we can use to inspect and manipulate outside of 


Elasticsearch itself. 


echo 





negative: San Francisco Airport, radar tower. Negative. Transfer, SFO Museum Collection. 2011 032.0315. 


The third tool is called echo and copies (or echoes) one data 
source to another. There are lots of tools, many of them bundled 


with a computer's operating system, that do this already. What 


distinguishes the echo tool is that it uses the Go Cloud blob 
package https://gocloud.dev/howto/blob/ which allows it to 
read and write data from a variety of different sources and storage 


providers. 


The echo tool has two parameters: -from and -to which are 
pointers to data sources (or "blobs") to read from and write to, 
respectively. If the former is empty then data is read from STDIN. 
If the latter is empty then data is written to STDOUT. For example: 


$> echo ‘hello world' | bin/echo 
hello world 


Which is literally the same as using the built-in Unix 
echo https://en.wikipedia.org/wiki/Echo_ (command tool, 


but slower and less efficient: 


$> echo ‘hello world' 
hello world 


Here's an example of using our custom echo tool to read data from 
STDIN and write it to a local file on disk: 


$> echo ‘hello world' | bin/echo -to 'file:///usr/local/data/test' 


$> cat /usr/local/data/test 
hello world 


And this is how we would read that back, sending the data to 
STDOUT: 


$> bin/echo -from 'file:///usr/local/data/test' 
hello world 


Again, all of these things can be accomplished using built-in echo 


and cat https://en.wikipedia.org/wiki/Cat_(Unix Unix 


command-line tools: 


S$echo 'hello world' > /usr/local/data/test 
$> cat /usr/local/data/test 
hello world 


The value of our custom echo tool is it supports reading and 
writing data to any source that implements the Go Cloud blob 
interface https://gocloud.dev/howto/blob/ .The blob 
interface allows us to read and write data to a local filesystem as 
well as remote storage providers like Amazon's S3 # or Google's 


Cloud Storage #_ services. 


For example, here's how we would read data from STDIN and 


write it to a file in S3: 


$> echo 'this is a test' \ 


| ./bin/echo \ 
-to 's3://s3-bucket/misc/test.txt?region=us-east-1' 


And then read the file we've just written sending the data to 
STDOUT: 


$> bin/echo \ 
-from 's3://s3-bucket/misc/test.txt?region=us-east-1' 
this is a test 


Data sources are defined using the Go Cloud URL 
syntax https://gocloud.dev/concepts/urls/ allowing us to 
reuse the same echo tool in a variety of settings by changing the 


URL that it uses to read or write data. 


If we combine our custom echo tool with the dump tool we can 


chain them together and export our Elasticsearch database as bzip2- 
encoded file of line-separated JSON files stored in S3, in a simple 
pipeline of commands, like this: 


$> bin/dump \ 
-elasticsearch-endpoint http://localhost:9200 \ 
-elasticsearch-index millsfield \ 


| bzip2 \ 


| bin/echo \ 
-to 's3://s3-bucket/millsfield.bz2?region=us-east-1' 


An Elasticsearch index could be restored from an export stored in 
S3 like this: 


$> bin/echo \ 
-from 's3://s3-bucket/millsfield.bz2?region=us-east-1' \ 


| bin/restore \ 
-elasticsearch-endpoint http://localhost:9200 \ 
-elasticsearch-index millsfield \ 
-is-bzip \ 
-stdin 


runtimevar 





negative: San Francisco Airport, radar tower. Negative. Transfer, SFO Museum Collection. 2011 032.0315. 


The fourth tool, called runtimevar, is a command line wrapper 
around the Go Cloud runtimevar 


package https://gocloud.dev/howto/runtimevar/ .The 


runtime package defines itself as: 


..an easy and portable way to watch runtime 
configuration variables. This guide shows how to 
work with runtime configuration variables using the 
Go CDK. Subpackages contain driver 
implementations of runtimevar for various services, 
including Cloud and on-prem solutions. You can 
develop your application locally using filevar or 
constantvar, then deploy it to multiple Cloud 


providers with minimal initialization reconfiguration. 


This tool processes a Go Cloud runtime URL 

variable https://gocloud.dev/howto/runtimevar/#opening 
and emits its string value to STDOUT. As with the echo tool the 
value of the runtimevar tool is that it supports a variety of 
sources https://gocloud.dev/howto/runtimevar/#services 
from an in-memory (constant) values, files on disk or even remote 


parameter storage services. 


For example, this is how the runtimevar tool would be used 
with a in-memory 


value https://gocloud.dev/howto/runtimevar/#local 


$> bin/runtimevar 'constant://?val=hellotworld' 


hello world 


And this is how the tool would be used with a value stored in the 
AWS Parameter Store 


service https://gocloud.dev/howto/runtimevar/#awsps 


$> bin/runtimevar 'awsparamstore://sfomuseum-secret-parameter?region=us-east-1' 


s33kr3t 


And this is how the tool would be used in a shell script retrieving 
and storing a different PASSWORD value depending on whether the 


script was run in a development or production environment: 


# use a constant value for local development 
# use a password stored in AWS Parameter Store for production 


PASSWORD_URI="constant://?val=password" 
if [ ${IS_PRODUCTION}="1" ] 
then 
PASSWORD_URI="awsparamstore: //sfomuseum-password?region=us-east-1" 


end 


PASSWORD= runtimevar ${PASSWORD_URI}~ 


Like the echo tool the same runtime tool is able to be used in a 
variety of different settings simply by changing the URL of the 


variable we need to retrieve. 





negative: San Francisco International Airport (SFO), baggage area. Negative. Transfer, SFO Museum Collection. 
2011 .032.0721. 


All of these tools are currently in use at SFO Museum and we have 
published the source code for each to our GitHub 

account https://github.com/sfomuseum . We would welcome 
any suggestions or contributions to improve them. These aren't big 
or flashy tools but they are helpful and by sharing them we hope to 
encourage others in the sector to publish their own small, focused 


tools. 


e https://github.com/sfomuseum/go-jsonl- 
elasticsearch https://github.com/sfomuseum/go- 


jsonl-elasticsearch 


e https://github.com/sfomuseum/go-cloud-blob- 
echo https://github.com/sfomuseum/go-cloud- 


blob-echo 


e https://github.com/sfomuseum/runtimevar https: // 


github.com/sfomuseum/runtimevar 
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Did I mention that I like cut 
outs https://www.aaronland. info/weblog/2020/02/24/scrolli 


ng/#cut-outs ? 
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the same as everyone else 
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peanuts in red sauce 


webster-cli 


webster-cli 
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Slide from the this is my brick / there are many like it but this one is 
mine talk I did in 2014. 


For a long time I have wanted a command line 


tool https: //www.nealstephenson.com/in-the-beginning-was- 
the-command-line.html 


for rendering PDF files from URLs 
complete with support for print 
CSS https: //www.w3.org/community/cssprint/ 


. Something like 
Paul Hammond's 


webkit2png https://paulhammond.org/webkit2png but for PDF 
files. Apparently this is about to become very 


easy https://developer.apple.com/documentation/webkit/wkwebv 


iew/3650490-createpdf iniOS 14 and MacOS 11 but until now it’s 


been a nuisance. Over the weekend I managed to get the starter code 


for a MacOS command-line tool to generate PDF files from websites, 


written by Matt Smollinger https://github.com/msmollin a 


former colleague at Mapzen, working again. 


It works like this: 


$> webster-cli https://aaronland. info/weblog/2020/08/24/peanuts --height 9 --width 6 


And it produces a file that looks like this: 


eee @ peanuts.pdf (page 2 of 11) 
Oia i/agt £\-JaT Oa 


Y peanuts.pdf 


webster-cli 





You can see the actual PDF file here. 


That's all it does. I was asked by a friend why this tool was necessary 
and this is what I said: 


Mostly for making print-on-demand-ready 

editions https://www.aaronland.info/weblog/2019/ 
01/30/something/#millsfield of personal websites 
so that there is a copy of that work that doesn’t require 
electricity https: //www.aaronland.info/weblog/201 
7/02/20/mostly/#museumnext to work. I’ve done the 
same for work stuff like baking a PDF copy of the 
Mapzen weblog https://www.mapzen.com/blog 

(and uploading it to the Internet 

Archive https://archive.org/search. php? 
query=mapzen%20weblog ) when it wasn’t clear what 
would survive the shutdown of the 

company https://www.aaronland.info/weblog/201 


7/12/31/things/#chapter-two 


The goal is never to supplant websites or plain vanilla 
HTML but to use them as the seed for the PDF file, hence 
the use of WebKit which has proper support for print 
CSS. 


In a museum context it becomes an interesting way to 
think about generating custom on-demand “catalogs” for 
people. This is especially interesting for a place like SFO 
Museum https://millsfield.sfomuseum.org/ 

since people will be getting on planes with limited or 


garbage internet access. 


van 
cei” 
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Examples of objects from the Cooper Hewitt collection rendered using 
print stylesheets. 


We did some work around print stylesheets for museum objects at the 
Cooper Hewitt. In a 2013 blog post titled "cmd- 
P" https://labs.cooperhewitt.org/2013/cmd-p/ Katie Shelly 


wrote: 


What we realized in looking at all the printouts, though, 
is that the simplified view of a collection record 
resembles a gallery wall label. And we’re currently knee- 
deep in the wall label discussion here at the Museum as 
we re-design the galleries (what does it need? what 
doesn’t it need? what can it do? how can it delight? how 


can it inform?). 


webster-cli https://github.com/aaronland/webster-cli_ is not 
the first tool to generate PDF files from webpages. I used to use a tool 
called wkpdf https://github.com/plessl/wkpdf until it stopped 
being maintained. There is also the 

wkhtmltopdf https://github.com/wkhtmltopdf/wkhtmltopdf 

tool which has been around for ages. I haven't tried using it recently but 
in the past I've found the support for print stylesheets to be lacking and 
it has a long list of dependencies that make it difficult to install. Unlike 
these tools webster-cli https: //github.com/aaronland/webster- 
cli is anative MacOS application. My hope is that this will give it a 
little more stability over the long run while also ensuring access to all 


the latest features when it comes to rendering web pages. 


I've taken Matt's original tool, called 
webster https://github.com/msmollin/webster , and broken it in 


to two pieces: 


e webster-cli nttps://github.com/aaronland/webster- 


cli, the command line tool I described above. 


e swift-webster https://github.com/aaronland/swift- 
webster , a generic Swift package that does all the work 
of producing PDF files. 


One of the reasons for breaking things up this way is that, while 
thinking about how SFO Museum might use these tools to generate a 
catalog of web pages on demand I realized that this is code that will 
only work on a MacOS or iOS device. Even though 

Swift https://swift.org/ , the programming language used to 


write the tool, has been ported to Linux, and can even be used to write 


Lambda functions https://swift.org/blog/aws-lambda- 
runtime/ in AWS, the WebKit 

framework https://developer.apple.com/documentation/webki 
t which handles all the work rendering web pages is only available 


on operating systems produced by Apple. 


In order to automate the production of PDF files it made sense to 
separate the code that does all the work from the code that triggers that 
work. That trigger might be a command line application running on my 
laptop or, eventually, a web 

service https://github.com/apple/swift-nio so that a process 


running on another computer can trigger the creation of a PDF file. 





I mention this because one of the arguments I have been trying to 


advance recently is that the cultural heritage sector needs to revisit how 
it produces software, and other 

technologies https://www.aaronland. info/weblog/2020/04/06/fut 
ures/#mw20 , used by and for the community. An abbreviated version 


of that argument is: 


e The costs of outsourcing the kinds of digital projects that 
cultural heritage institutions want to pursue are 
unsustainable. In the short-term these costs are outside the 
reach of most institutions so they never happen in the first 
place. Even for those that can afford these them, the costs 
associated with long-term maintenance or adapting 
projects to future needs are often even more expensive than 


the original effort. 


e There is a widespread belief in the sector that it will never 
be able to attract or retain the staff needed to undertake 
these projects in-house. No single museum or library will 
ever enjoy the 400-person software engineering staffs that 
are so common in the private sector but there is a lot of 
room between 400 and "nothing". The belief that it's a 
binary option has become a self-fulfilling prophecy in 


many organizations. 


e This belief has led to the creation of any number of 
consortia, typically funded by large donor organizations, 
to produce monolithic applications that service whole 
slices of the cultural heritage sector. Even with the best of 


motivations these initiatives almost never work as intented. 


e Every collection practice is unique and these differences 


are made manifest in how they intersect with digital 


technologies and the demands they place on them. It is 
unrealistic to expect that a single umbrella organization, 
often operating within its own finite budget and staffing 
constraints, could service the wide range of needs and 


concerns of its members. 


e Member organizations rarely have the technical staff on 
hand to discuss, at a detailed implementation level, the 
kinds of features and functionality needed for their specific 
projects so needs and requirements are only ever discussed 
in abstract generalities. The net result is, unsurprisingly, a 
lowest-common denominator solution that everyone 
tolerates because of the unspoken belief that there is no 


alternative but that no one really likes. 


In as much as there are organizations with small, or limited, technical 
staff I think that there needs to be a shift in the way we produce the 
software and tools used to service our respective digital initiatives. 
Although there is often a commonality of needs between two or more 
cultural heritage institutions there is rarely any overlap in how those 


needs are delivered or implemented. 


In fairness the library and archives sector has had a better success, 
building and delivering shared tools, but the same can not be said of 
museums. Common tooling that aims to address the specific quirks of 
anything but a single museum have, historically, become an unweildly 


burden that no one wants to shoulder. 


Instead I believe that we should undertake the effort to break apart the 
tools we do build in to layers of generic functionality that aren't specific 
a given organization or project. These small, focused 


tools https://millsfield.sfomuseum.org/blog/2020/08/04/small 
-tools/ are the things that we should be sharing rather than finished 
projects. These should be the common layer of plumbing and a "kit of 
parts" that we can all reach to, that underpin the different and varied 


initiatives we undertake. 


Implicit in this argument is the idea that there is someone in an 
organization to reassemble this kit of parts in concert with the specific 
needs and technologies bespoke to that organization. You have to 
believe that it's possible to have an in-house technical staff. Conversely, 
that in-house technical staff needs to ensure that their work is 
economically viable and one way to do that is by sharing tools that can 


be used, and improved upon, across the cultural heritage sector. 


webster-cli https://github.com/aaronland/webster-cli_, for 
example, doesn't address what your print stylesheet looks like, nor does 
it say anything about which web pages it renders. It doesn't even handle 
combining multiple PDF 

files https://pdfbox.apache.org/2.0/commandline.html#pdfmerge 
r intoasingle "catalog". It does exactly one thing: It automates the 
production of a PDF file from a URL. The many different uses for that 
PDF file are left up to individuals using webster- 

cli https://github.com/aaronland/webster-cli to decide and to 


see through to completion. 


The cultural heritage sector has never been able to afford the "400- 
person software" engineering staffs that are the norm in the private 
sector. Nor can it continue to afford the cost of third-party client- 
services technology providers. I believe it can, should and needs to 
afford something at the intersection of those two extremes and 


"nothing". 


Fostering a practice of small, focused tools is one part of how we can 
make that possible. 


2020-08-24 
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the purpose of open data Is 
to save us from ourselves 
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One day I am going to write about the problem of museum website 
footers... 


Some time in the last couple of weeks the digital team at the 


Cooper Hewitt disabled the "random object" 

page https://collection.cooperhewitt.org/objects/random 
/ on its collection website as well as the corresponding 
cooperhewitt.objects.getRandomObject API method. 
This follows the disabling of the search by 

colour https://slate.com/human- 
interest/2013/11/smithsonian-cooper-hewitt-s-new-beta- 
website-lets-—you-—browse-the-online-collection-by- 
color.html webpages last year, even though they were 
consitently the most popular way to browse the 

collection https://slate.com/human- 
interest/2013/11/smithsonian-cooper-hewitt-s-new-beta- 
website-lets-you-browse-the-online-collection-by- 


color.html 


While this is disappointing to me personally, since I implemented 
these features and many of us thought they were both a 

fun https://labs.cooperhewitt.org/2012/lost-collection- 
alpha/ and genuinely useful 

way https://labs.cooperhewitt.org/2018/making-dive-into- 
color/ to introduce visitors to the collection, these decisions are 
the discretion of the museum and the current digital team. They are 


free to do whatever they want. 


What is genuinely disappointing to me, though, is the fact that the 
API 

methods https://collection.cooperhewitt.org/api/methods 
/ were disabled without any notice or warning. We have grown 


accustomed, in the last decade, to the practice of companies and 


platforms changing or disabling their services with little or no 
regard to the external users of their services. One only has to look 
at the flip- 

flopping https: //www.theverge.com/2018/5/16/17362138/twit 
ter-api-third-party-apps-changes-explained around who 
can use which parts of the Twitter API, and under what conditions, 
since it was first launched in 


2006 https://en.wikipedia.org/wiki/Twitter#Developers 


To the extent that the cultural heritage sector, and specifically 
museums, have a long history of riding the coattails of the private 
sector when it comes to technology decisions the fact that we're 
starting to see similar behaviour when it comes to our own APIs 


should be no surprise. 


HOME EXPLORE THE COLLECTION~ You- 








return to method documentation Introduction to the Cooper Hewitt API 





API Methods 
REQUEST Pacts {Pi Formats 
Create a New API Key 
: Your API Keys 
tt.org/rest/?method=@yyytai-aaeh Saeed access_tok 
Your Access Tokens 


See the access token inthe request above? It is a time-sensitive token 
for the purposes of the API Explorer and for copy-pasting example requests 
in the moment but be aware that it will expire. 





RESPONSE 
{ 
"error": { 
“code": 999, 
“error": “Random objects are disabled", 
"message": "Random objects are disabled" 
i, 
"stat": “error”, 


“event_publishing_state": "ok" 


In fairness, the terms of service for the Cooper Hewitt API state: 


This Application Programming Service (API) is 
provided as-is and you agree to play nicely and not 
abuse abuse it and that we, the API service provider, 
reserve the right to change things at our discretion 
with or without notice. This includes disabling 
access to the API if your applications starts 


misbehaving. 


Basically: Play nicely and don't be creepy. 


I wrote that text sometime in 2012 or 2013 and it really should have 
been revised, when the museum reopened in 2014, to offer a little 
more clarity and guarantees around the service. Live and learn. In 
2019, speaking at the Museums and the 

Web https://www.aaronland. info/weblog/2019/04/08/post/# 
mw19 conference about the work SFO Museum is doing on the 
Mills Field 

website https://www.aaronland.info/weblog/2019/04/04/phas 


e-shifting/#mwl19 I said: 


We have changed the order of things to publish the 
open data representation first and then, from there, to 


build our own websites and services on top of that. 


Everything I've described so far has been built using 
the same raw materials that we've made available for 
you to do something with. This introduces a non- 
zero cost in the build process for the public-facing 


museum efforts but we believe it's worth the cost. 


But why, right? 


First of all we want other people to build new 
interfaces and new services, new "experiences" even, 
on top of our collection so this is a way to keep 
ourselves honest. If we can't build something with 


this stuff why should we imagine you will? 


Second, we want to ensure that the data we release 
and the manner in which it is published, is actually 
robust and flexible enough to engender a variety of 
interfaces and uses because we need that variety. It is 
important to the museum because I don't believe 
there is, or should be, only one master narrative in to 


the collection. 


There is a long and celebrated tradition in the museum sector of 
digital teams scraping their own websites to provide unofficial API 
access to their own collections. While this kind of "can do" spirit is 


laudable it is mostly, I think, a damning indictment of the sector as 


a whole. This sort of thing shouldn't be necessary and the fact that it 
is shows either that we've learned nothing since the idea of public 
service-level API methods became commonlace or, worse, that we 
were never serious about open and accessible APIs in the first 


place. 


The immediate consequence of the Cooper Hewitt disabling the 
cooperhewitt.objects.getRandomObject API method 
is that it breaks the 

wunderkammer https://github.com/aaronland/ios- 
wunderkammer application that I've been working 

on https://www.aaronland.info/weblog/2020/06/16/revisiti 
ng/#pen since June of this year. As consequences go that's pretty 
low. I am probably the only person using the application. If the 
wunderkammer application were distrubuted through the app store 
with users, maybe even lots of users, the consequences would be 


pretty high. 


@Pinterest Today Explore Q 


Random Button 


Collection by Micah Walter 
110 Pins 201 Followers 





Regency House Regency Era 1700s Dresses Fabric Purses 


Drawing, Salon Interior = ¥ 
with Gabriel d'Arjuzon... 

In this small genre scene, the 
Count d'Arjuzon, plays the violi... 


@ wican water 


Reticule (France), late = ¥ 
18th century 

Flat square bag with drawstring 
top of white silk bobbin lace... 


@] recon war 


Alexander Girard Graphic Design 
Sample Book, Wallpapers ¥ 
Designed by Alexander... 


Thirty-seven samples of 
walloaper, featuring eight. 


@ recon war 







Privacy 


DieterRems Green And Grey 


T52Clairtone Portable Y 
Radio, 1961 


Flat rectangular grey-green 
plastic housing. Transparent 





Porcelain Dolls Value Fine Porce! 


Figure of aDog Figure, = 
19th century 

‘Small long-haired dog, sitting, 
head slightly turned; white wit. 


@ Micah wetter 


Match Boxes Bamboo Leaves 


Bamboo Leaves y 
Matchsafe, ca. 1900 


Rectangular, rounded corners, 
featuring bamboo leaves and... 


@ mican warer 





Mailing Labels Design Museum 


Print, NeXt, Inc. Mailing = Y 
Label, 1986 

Company sticker imprinted with 
the NeXT logo, a cube in black 


@ vican water 


Golden Color Design Museum 


v 


Waistcoat (France), mid- 
18th century 

Gentleman's waistcoat in dark 
golden color has horizontal 


@] rican water 


a 


== 
Book Area Phone Books office 
Phonebook Telephone, = Y 
World'sFair DesignMuseum Ff; 1980S 


a \ Ablack telephone connected to 
i is Science Glass, ca. rectangle keypad with a hinge... 
. Tall, slightly tapering cylindrical QB Micah Walter 
Piano Lamps DeskLamp Table form of clear “frosted” glass... 


v 
(@ vican watter 





Model 404 Piano Lamp, 
1928 

Lamp composed of geometric 
elements: horizontally mounte... 


@ vicah watter 














eas 7 





Textile Prints 


Textile Texture 


Sidewall, Daphnis, 1922 ¥ 
Simplified and semi-cubistic 
leaf forms interspersed with... 


@ vicar wetter 









Paper Embroidery — Crewal Embro! 


Print, Berlin Wool Work: 
Hunting Dog, ca. 1879 

Design on squared paper for 
Berlin wool work; a dog facing... 


@ Micah wetter 


Guerrilla Girls 


TheNew Wave 
Poster, Artificial Nature, 
Poster for Exhibition at... 


Photographic color 
reproduction of a beach with a... 





Calligraphy Alphabet 


Design Mu: 
Book, Livre Curieux et = 
Utile pour Les Scavans, ... 


Book of 153 pages of 
ornamental monogrames and... 


@ ican water 





Double window 


Butcher Shop 


Butcher's Shop Model, ca. Y 
1800 


Model of a butcher shop 
composed of a shadow-box,.. 


GB rican water 


Micah Walter's Cooper Hewitt Random Button Pinterest board 


Best practice dictates that you should always write your programs 


defensively when using third-party APIs, assuming for one reason 


or another that they will eventually fail. Calling the 


cooperhewitt.objects.getRandomObject or any other 
API method should be considered a brittle operation and ideally an 
application will trap those failures accordingly. That's very different 
than suddenly introducing a deliberate and consistent failure in to 
one or more applications which may have lengthy or burdensome 
update procedures and that require user-action (downloading a new 


application) to remedy the situation. 


It's just rude. There might be a valuable debate to be had about 
whether or not rudeness is actually a core value in the cultural 
heritage sector but, at least publicly, we say it's not and I believe 
that same commitment should extend to the things we do digitally. 


My argument here is not that I have been adversely or negatively 
impacted, in any serious way, by the Cooper Hewitt's decision to 
remove a single API method. As I mentioned scraping museum 
websites and building bespoke databases is not very complicated. I 
had to do that recently, compiling all the image URLs for 

objects https://github.com/aaronland/go-metmuseum- 
openaccess#images-1 published in The Metropolitan Museum of 
Art's Open Access 

Initiative https://github.com/metmuseum/openaccess dataset. 
I think I could do the same for the Cooper Hewitt collection in an 
afternoon. My argument is that I shouldn't have to, especially not 
after the fact. 


private func getRandomURL(database: FMDatabase) -> Result<URL, Error>{ 
let q = "SELECT url FROM oembed ORDER BY RANDOM() LIMIT 1" 
var str_url: String? 
do { 
let rs = try database.executeQuery(q, values: nil) 
rs.next() 
guard let u = rs.string(forColumn: “url") else { 
return .failure(SmithsonianErrors. invalidURL) 
ap 
str_url =u 
} catch (let error) { 
return .failure(error) 
i 
guard let url = URL(string: str_url!) else { 
return .failure(SmithsonianErrors. invalidURL) 


} 


return .success(url) 


Which brings me to the point of writing this blog post in the first 


place: I don't have to. 


Much, but not all, of the Cooper Hewitt 

collection https://collection.cooperhewitt.org/ iS 
published as part of the Smithsonian's own Open 

Access https://github.com/Smithsonian/OpenAccess 

metadata initiative. Since the wunderkammer application already 
supports local databases of Smithsonian 

objects https: //www.aaronland. info/weblog/2020/07/07/acti 
on/#wunderkammer I can simply remove all the custom code to 
deal with the Cooper Hewitt 

API https://github.com/aaronland/ios- 


wunderkammer/blob/master/wunderkammer/CooperHewitt.swif 
t and continue browsing random objects like I would any other 


Smithsonian collection. 


That's the good news. I also can't help but feeling like, at the same 


time, this is really the bad news. 


Whatever the theory says about the value of cultural heritage 
institutions publishing open data, the practice appears to be one 
where the immediate benefit is shielding people from the constant 
indecision, churn and lack of long-term commitment in the cultural 


heritage sector itself. 


We have changed the order of things to publish the 
open data representation first and then, from there, to 


build our own websites and services on top of that. 


We can and we should do better than having to build in safeguards 
to protect the things we do as a sector, for our own institutions and 
the public that we claim and some of us are mandated to serve, 
from ourselves. There should be no celebration in that, only 


disappointment. 





2020-09-08 


this is the story | want to 
remember 


"| need to software preservationist my blog... 


"| need to software 
preservationist my blog 
first." 


This morning Tom Carden http: //www.tom-carden.co.uk/ 
wrote a lovely Twitter 

thread https://twitter.com/RandomEtc/status/130409389692 
7064065 about Kemal Enver's 

work https://sebchan.substack.com/p/48-on-planetary-in- 
2020-curatorial to resurrect the Planetary 

application https://collection.cooperhewitt.org/objects/3 
5520989/ that Cooper Hewitt acquired in 

2013 https: //mw2014.museumsandtheweb.com/paper/collectin 
g-the-present-digital-code-and-collections/ .I made 
screenshots of the thread since I lack confidence that I'll be able to 
find it on Twitter in any meaningful amount of future-time and this 
is the story that I want to remember. My hope is that Tom will 
republish the thread on his own blog so I can link to that but until 


then this will have to do. 


Thread 


Tom Carden @RandomEtc - 32m v 
You might remember earlier this year that @kemalenver resurrected 
Bloom's old Planetary app. It's free now - if you didn't catch it then, check 
it out! 


@ Tom Carden @Randomete - Jun 8 
®& © & Kemal did the hard work to get our old Planetary app 


working again. Open source works! Throw him a buck and explore your 
music collection as a galaxy! twitter.com/kemalenver/sta... 


01 tT 2 01 wy 


Tom Carden @RandomEtc - 32m v 
We caught up with Kemal and the Cooper Hewitt crew last night (US) / 
yesterday morning (AU), and chatted about some of the changes he had 
to make to get it working again. 


oO 1 am g & 


Tom Carden @RandomEtc - 32m Vv 
The process was roughly: 

- find the right compiler settings (trial and error) 

- find a close enough version of the @lipcinder dependency (we didn't 
bundle it) 

- find a close enough version of boost 

- fix things that apple had removed (more on this later) 

- fix small app bugs 


oO 1 wv Qg wy 


Tom Carden @RandomEtc - 32m Vv 
This is remarkable to me. We expected that our OpenGL ES1 era graphics 
code would be obsolete by now, but apparently it still builds and runs, 
despite Apple's emphasis on Metal. 


oO 1 al Qg wy 


Tom Carden @RandomEtc - 32m Vv 
We expected that the music library integration we created with @notlion 
would be broken in the streaming/cloud era, but it's still working as-is! 


QO 1 can Qg nar 


Tom Carden @RandomEtc - 32m v 
We didn't expect, but I'm not surprised, that our threaded asset and 
texture loading code was buggy. But Kemal was able to remove it fairly 
cleanly, and new devices are *so fast* that it wasn't necessary any more. 


0 1 a Qg na 


Tom Carden @RandomEtc - 32m Vv 
We also didn't expect: our custom device orientation code was obsolete. 
This is an area of functionality that Apple has deprecated fully - it's a no- 
op now. 


QO 1 im gO na 


Tom Carden @RandomEtc - 32m v 
Small issues like this (along with bigger issues of app review, proliferation 
of device form factors, and obsolescence of OSs) are chasing creative 
coders off the platform, as their apps are broken or they don't have the 
hooks they need any more. No budget, no maintenance. 


QO 1 1 01 na 


Tom Carden @RandomEtc - 32m v 
Kemal hard-coded our app to landscape. 


It's amazing that that's the only invasive change he had to make, almost 
ten years on. | expected us to need compatibility layers, or rewrites to 
shaders. | expected the music library integration wouldn't make it. 


QO 1 tr O.4 wy 


Tom Carden @RandomEtc - 32m v 
But the other lesson here for app preservationists: bundle your 
dependencies. Document the versions you used. Bake in your compiler 


settings (don't leave them set to "default" because implicit settings are 
hard to recover). 


O41 a Qg nar 


Tom Carden Vv 
@RandomEtc 


At the time @cooperhewitt acquired the app and we open 
sourced it, @sebchan and @thisisaaronland theorized 
that software preservation was a bit like a zoo. We knew 
we needed to keep the app alive somehow. 


9:26 AM - Sep 10, 2020 - Twitter Web App 


2 Likes 
2) a Qg a 
Tom Carden @RandomEtc - 32m v 
Replying to @RandomEtc 


When @kemalenver got it working again, | realized that software 
preservation is more like re-enacting a performance. The documentation 
trail is key. There's no objective reference available for what it was like 
before. It hasn't been continuously preserved. 


O1 a O03 ty 


Tom Carden @RandomEtc - 32m v 
So maybe not zoo? Maybe more like Jurassic Park. We can't be sure that 
Kemal's recreation is authentic, because we can't compare to the original. 
I'm pretty sure the frame rate is better. 


O 1 a QO 1 na 


Tom Carden @RandomEtc - 32m Vv 
To my (original author's) eyes the details are all there, but the flaws jump 
out - were they there before? | can't recall. But @flight404's artistry still 
shines through, and I'm grateful for that. Thanks again @kemalenver and 
@cooperhewitt for the walk down memory lane! 


@) n to) ity 


thisisaaronland @thisisaaronland - 1m v 
@RandomEtc wrote a lovely thread about @kemalenver 's work to 
resurrect the Planetary application that @cooperhewitt acquired in 2013 / 


| hope he republishes it as a blog post so | don’t have to link to a bunch of 
screenshots in the future — 


} Tom Carden @RandomEtc - 38m 


You might remember earlier this year that @kemalenver resurrected 
Bloom's old Planetary app. It's free now - if you didn't catch it then, 
check it out! twitter.com/RandomEtc/stat... 


Show this thread 


O14 ita) g i ill 


Tom Carden v 
@RandomEtc 


Replying to @thisisaaronland @kemalenver and @cooperhewitt 
| need to software preservationist my blog first. 


10:04 AM - Sep 10, 2020 - Twitter Web App 


>) tr ga 
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2020-09-10 


things | have written about elsewhere 
#20200914 


zoomable.images.js 


zoomable.images.js 





Cable Staged 
CARY 





caeeny ea ae a 


branched 
) olan 





Architectural design drawing: San Francisco International Airport (SFO), Skidmore, Owings & Merrill 
(SOM) https://millsfield.sfomuseum.org/objects/1511910401/ . Paper, ink. Skidmore, Owings, & Merrill, SFO Museum Collection. 
2000.086.008 https: //millsfield.sfomuseum.org/objects/1511910401/ . 


This was originally published on the SFO Museum Mills Field 
weblog https://millsfield.sfomuseum.org/blog/2020/09/14/js-zoomable/ ,in 
September 2020. 


We've updated the user interface elements that control how a static image can be made 
"zoomable" making them easier to use and more portable across a number of different 

settings.. We introduced "zoomable" 

images https://millsfield.sfomuseum.org/blog/2020/02/03/zoomable/ earlier 
this year. They enable a viewer to toggle between a static and a tiled version of an 


image allowing them to zoom in and out of details in that image. 





J alo) Wardelelant-le) (=m lant-\e (=) 


In the first iteration the control for loading zoomable image tiles for a static image was 
a button located beneath the image. 





Image by SFO Museum. It was taken on Jul 16, 2015. 


In this iteration the control is graphical and sits "inline" with the image, in the top right 


hand corner. 





When you click the "zoomable" button the tiled images are loaded fullscreen now. 
Before we used to load the tiles in a larger viewport than the original image but not 
fullscreen. We think this is a better interaction model, especially on mobile devices. 


Search results for “construction” 
There are 1,221 results for this query, grouped by the following types: 


object 1,208 and exhibition 9 and publicart 4 








201.032.1785. 201.032.1756. 201.032.1790. 





by SFO Museum mage by SEO Museum 








The new "zoomable" control is available on both pages with a single image as well as 
pages with multiple images, like search 
results https://millsfield.sfomuseum.org/search/?q=construction ,Wwherea 


button under each image was cumbersome and distracting. 


Note: From this point on I'll be covering the technical details of how these new 
"zoomable" controls work. If that's outside your area of interest you can stop reading 
here and just enjoy the improved zoomable images on the Mills Field 


website https://millsfield.sfomuseum.org/random 









TO PROVIDE ADEQUATE TERMINAL FACILITIES TO MEET EXISTING PASSENGER 
VOLUME i 


. TO PROVIDE ADEQUATE AUTOMOBILE PARKING FACILITIES AND TO DECREASE 
TRAFFIC CONGESTION 


. TO PROVIDE IMPROVED AIRFIELD LANDING AND APRON FACILITIES FOR THE NEW 
GENERATION WIDE-BODIED AIRCRAFT 


. TO ACCOMODATE THE ANTICIPATED FUTURE GROWTH IN AIR TRANSPORTATION 
DEMANDS 


Photograph: San Francisco International Airport (SFO), expansion program and 
construction https://millsfield.sfomuseum.org/objects/1511924423/ , Photograph. Transfer, SFO Museum Collection. 
1997.52.084.099 https://millsfield.sfomuseum.org/objects/1511924423/ . 


The JavaScript programming https://developer.mozilla.org/en- 
US/docs/Web/JavaScript language, which is bundled with all modern graphical web 
browsers, is necesary in order to toggle between static and "zoomable" images. 
Sometimes, though, people disable 

JavaScript https: //www.smashingmagazine.com/2018/05/using-the-web-with- 


javascript-turned-off/ support in their web browser. 


In order to ensure that "Zzoomable" images are an improvement to the Mills 


Field https://millsfield.sfomuseum.org website, and not a requirement for 
using it, we've settled on a practice of starting with plain-vanilla HTML markup for 
images that contains structured data which can be acted on if and when JavaScript is 


present. 


This approach owes a debt of inspiration to Shawn Allen's HTMAPL 
plugin https://github.com/shawnbot/HTMAPL for the jQuery library. HTMAPL 


describes itself as a "basic HTML vocabulary for describing both interactive and static 
geographic maps, with layers and markers". For example, you add the following 
HTML markup to your web pages: 


<div class="map" data-center="37.765,-122.413" data-zoom="11"> 
<div class="marker" data-location="37.7647463,-122.41951"> 
<a href="http://stamen.com">Stamen</a> 
</div> 
<div class="controls"> 
<button data-action="zoomIn">+ in</button> 
<button data-action="zoomOut">- out</button> 
</div> 
</div> 


And HTMAPL takes care of all the work necessary to convert that in to an interactive 


map. Our equivalent markup for "Zzoomable" images looks like this: 


<div class="zoomable-image" id="zoomable-image-{IMAGE_ID}" data-image-id="{IMAGE_ID}"> 
<div class="zoomable-static" id="zoomable-static-{IMAGE_ID}"> 


<button class="btn btn-sm btn-light zoomable-button zoomable-toggle-tiles" id="zoomable-toggle-tilt 
<p id="zoomable-loading-{IMAGE_ID}" class="zoomable-loading" style="background-image:url({THUMBNATI] 


<img id="zoomable-picture-default-{IMAGE_ID}" class="zoomable-picture-default" src="{IMAGE_URL}" a? 
</div> 


<div class="zoomable-tiles" id="zoomable-tiles-{IMAGE_ID}" data-tiles-url="{TILES_URL}"> 
<div class="zoomable-map" id="zoomable-map-{IMAGE_ID}"/> 
</div> 


</div> 


At the top of each page we load CSS https: //developer.mozilla.org/en- 
US/docs/Web/css _ styling information for rendering the images on a page whether or 


not JavaScript is enabled. This includes styles for placing the "zoomable" control 
which is hidden by default. 


<link rel="stylesheet" type="text/css" href="zoomable.images.rollup.css" /> 


We also load Javascript libraries which will look for all the elements in the webpage 
with a zoomable-image CSS class and, using structured data contained in these 
elements and their children make all the necessary adjustments to enable "zoomable" 


image controls. 


<script type="text/javascript" src="zoomable.images.rollup.js"></script> 

<script type="text/javascript"> 

window. addEventListener("load", function load(event) { 
zoomable.images.init(); 


ye 
</script> 


In the HTML example above there are a lot of {SOMETHING} style variables. I'll walk 
through the markup step-by-step in order to describe them. 


<div class="zoomable-image" id="zoomable-image-{IMAGE_ID}" data-image-id="{IMAGE_ID}"> 


This is the top-level element for a "zoomable" image. The { IMAGE_ID} variable is 


whatever you want it to be. It only needs to be unique to a specific image. 


<div class="zoomable-static" id="zoomable-static-{IMAGE_ID}""> 


This is the top-level element for a static image. 


<button class="btn btn-sm btn-light zoomable-button zoomable-toggle-tiles" id="zoomable-toggle-tilt 


This is the "Zoomable" control element. It is hidden by default. 


<p id="zoomable-loading-{IMAGE_ID}" class="zoomable-loading" style="background-image:url({THUMBNAI] 
<span class="zoomable-loading-text">loading</span> 
</p> 


This is text that is overlaid on the {THUMBNAIL _URL} image, described below. Like 
the thumbnail image it is hidden once {IMAGE _URL}, described in the next section, is 
loaded. 


Note the background-image CSS style, in the parent element, which contains the 
{THUMBNAIL_URL} variable. This is a smaller version of the static image you want 
to show. It will be hidden once {IMAGE_URL} is loaded. 


<img id="zoomable-picture-default-{IMAGE_ID}" class="zoomable-picture-default" src="{IMAGE_URL}" a? 


This is the static image itself, defined by the { IMAGE_URL} variable. This might also 
be apicture https://developer.mozilla.org/en- 
US/docs/Web/HTML/Element/picture element if you want to define multiple images 
to display based on the browser's screen size. On the Mills 

Field https://millsfield.sfomuseum.org website we use picture elements for 
object webpages https://millsfield.sfomuseum.org/random and img elements 
for "list view" pages, like exhibition 

images https://millsfield.sfomuseum.org/exhibitions/1159160649/images/ 


If JavaScript is enabled this element is hidden until the image is finished loading, at 
which point the thumbnail image and text above are hidden. If JavaScript is not 
enabled then the thumbnail image and text are hidden and this (image) element is 


visible and rendered as the image loads. 


</div> 
<div class="zoomable-tiles" id="zoomable-tiles-{IMAGE_ID}" data-tiles-url="{TILES_URL}"> 
<div class="zoomable-map" id="zoomable-map-{IMAGE_ID}"/> 


</div> 


</div> 


Finally, the container element for the tiled "zoomable" image. The tiles themselves are 

expected to be IIIF-style image tiles https://iiif.io/api/image/3.0/ and the 

{TILES URL} variable defines the location of a IF info. json document 
https://iiif.io/api/image/3.0/#5-image-information for the image in 


question. 





Image by SFO Museum nttps://millsfield.sfomuseum.org/images/sfomuseum/ . 


Here's a concrete example: This is the markup we're using to display the image for a 
1983 timetable for WestAir 
Airlines https://millsfield.sfomuseum.org/objects/1511938591/ , above. 


<div class="zoomable-image" id="zoomable-image-1527842879" data-image-id="1527842879"> 


<div class="zoomable-static" id="zoomable-static-1527842879"> 
<button class="btn btn-sm btn-light zoomable-button zoomable-toggle-tiles" id="zoomable-toggle-tilt 
<p id="zoomable-loading-1527842879" class="zoomable-loading" style="background-image:url(https://si 
<span class="zoomable-loading-text">loading</span> 
</p> 
<picture class="zoomable-picture" id="zoomable-picture-1527842879"> 
<source srcset="https://static.sfomuseum.org/media/152/784/287/9/1527842879_ Ag9JNIHX702LpjurG7 YB 
<source srcset=" ://static.sfomuseum.org/media/152/784/287/9/1527842879_ Ag9JNIHX702LpjurG7 YB 
<source srcset=" ://static.sfomuseum.org/media/152/784/287/9/1527842879_Ag9JNIHX702LpjurG7 YB 
<source srcset= ://static.sfomuseum.org/media/152/784/287/9/1527842879_ Ag9JNIHX702LpjurG7 YB 
<source srcset= ://static.sfomuseum.org/media/152/784/287/9/1527842879_Ag9JNIHX702LpjurG7 YB 
<source srcset= ://static.sfomuseum.org/media/152/784/287/9/1527842879_ Ag9JNIHX702LpjurG7 YB 
<source srcset=" ://static.sfomuseum.org/media/152/784/287/9/1527842879_Ag9JNIHX702LpjurG7YBI 
<img id="zoomable-picture-default-1527842879" class="card-img-top zoomable-picture-default image 
</picture> 
</div> 
<div class="zoomable-tiles" id="zoomable-tiles-1527842879" data-tiles-url="https://static.sfomuseum.« 
<div class="zoomable-map" id="zoomable-map-1527842879"/> 
</div> 
<div class="zoomable-caption" id="zoomable-caption-1527842879"> 
<div class="image-attribution">Image by <a href="https://millsfield.sfomuseum.org/images/sfomuseum. 
</div> 
</div> 





The JavaScript code we use to control "Zoomable" images is actually just a thin 
wrapper around a number of other libraries. They are the 


Leaflet https://leafletjs.com/ map rendering library and the extensions 
necessary to use IIIF image tiles https: //github.com/mejackreed/Leaflet-IIIF 


and to enable fullscreen 
display https://github.com/Leaflet/Leaflet.fullscreen 


e https://leafletjs.com/ nttps://leafletjs.com/ 


e https://github.com/Leaflet/Leaflet fullscreen https://github.com/Leaf 


let/Leaflet.fullscreen 


e https://github.com/mejackreed/Leaflet- 
HIF nttps://github.com/mejackreed/Leaflet-IIIF 


As well as our own leaflet-image-control https: //github.com/sfomuseum/leaflet- 
image-control library, and friends, which we use to enable saving images to your 
desktop from the detail of a zoomable image. We first wrote about this in the Map 
update, 2019-2020 https://millsfield.sfomuseum.org/blog/2020/01/10/map/ 


blog post last winter. 


e https://github.com/sfomuseum/leaflet-image- 


control nttps://github.com/sfomuseum/leaflet-image-control 


e https://github.com/mapbox/leaflet- 


image https://github.com/mapbox/leaflet-image 


e https://github.com/eligrey/FileSaverjs https://github.com/eligrey/F 


ileSaver.js 


In this way the JavaScript code that we wrote to control "zoomable" images does both 
quite a lot, if you count all the things that its dependecies do, and not very much at all 
if you only look at the functionality it alone 

provides https://github.com/sfomuseum/js-zoomable- 
images/blob/master/src/zoomable.images.js_ . This is part of our ongoing effort to 
develop, and share, small and focused 

tools https://millsfield.sfomuseum.org/blog/2020/08/04/small-tools/ that 
don't try to do too much and that are amenable to being reconfigured in new and 
different ways depending on the desired goal. 


(| 





Riven/River https://millsfield.sfomuseum.org/images/1377455253/ _, Jim Melchert. 2014. Grey porcelain ceramic tile, red & blue glaze. 
Collection of the City and County of San Francisco Commissioned by the San Francisco Arts Commission and the Airport Commission for the San 
Francisco International Airport. 2016.22.a-x https: //millsfield.sfomuseum.org/images/1377455253/ 


For example, our "zoomable" image code doesn't know anything about producing IIF- 
compatible image tiles https://iiif.io/api/image/3.0/ .It knows how to 
consume them but how they are made is left to another software program to figure out. 
We've written about how we produce and use IIIF images at SFO 

Museum https://millsfield.sfomuseum.org/blog/tags/iiif inthe past and 


we'll write more about that in the future. We've made some substantial improvements to 


the workflow we use for processing images and are eager to share them. 


Our hope is that if you already have IIIF image tiles that you can use them "as-is" with 
these particular bits of HTML markup and JavaScript code to enable simple and 


elegant, and pretty sophisticated, user interface controls to display "zoomable" images. 


As we demonstrated above we're using it in this blog post! 


This is "version 2", building and improving on the work we 

did https://millsfield.sfomuseum.org/blog/2020/02/03/zoomable/ to launch 
"zoomable" images. There are probably a few gotchas that we'll still need to address 
and I'd like to remove as much of the HTML markup, described above, as possible in 
future iterations. For example, the following bits of markup could probably be 


generated dynamically when a web page is loaded: 


<button class="btn btn-sm btn-light zoomable-button zoomable-toggle-tiles" id="zoomable-toggle-tile 
<p id="zoomable-loading-{IMAGE_ID}" class="zoomable-loading" style="background-image:url({THUMBNATI] 


And: 


<div class="zoomable-tiles" id="zoomable-tiles-{IMAGE_ID}" data-tiles-url="{TILES_URL}"> 
<div class="zoomable-map" id="zoomable-map-{IMAGE_ID}"/> 
</div> 


These are elements that are only necessary if and when JavaScript is present so we may 
as well let JavaScript create them before it goes to work. That will be "version 3" and if 
we've done our job right the time to get from version 2 to version 3, from version 3 to 
version 4,and soon https://millsfield.sfomuseum.org/blog/tags/zoomable , 
will be faster than the time it took to get from version | to version 2. In many ways the 
most important part of this work is just practicing the art of revisiting and improving 
these projects in small and manageable pieces. To learn how we make these 


improvements at the same time we're doing everything else. 
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Luggage label: Varney Speed Lines https: //millsfield.sfomuseum.org/objects/1511907595/  . Paper, ink, adhesive. Purchase, SFO Museum 
Collection. 1996.35.059 https://millsfield.sfomuseum.org/objects/1511907595/ . 


All of this code is open source and available in the js-zoomable- 
images https://github.com/sfomuseum/js-zoomable-images repository on our 


GitHub https://github.com/sfomuseum account. 


e https://github.com/sfomuseum/js-zoomable- 


images https://github.com/sfomuseum/js-zoomable-images 


The repository contains both the raw code that we've written on top of the libraries I 


described earlier: 


e https://github.com/sfomuseum/js-zoomable- 
images/blob/master/src/zoomable.images,js https: //github.com/sfomu 


seum/js-zoomable-images/blob/master/src/zoomable.images.js 
e https://github.com/sfomuseum/js-zoomable- 


images/blob/master/src/zoomable.images.css_ https: //github.com/sfom 


useum/js-zoomable-images/blob/master/src/zoomable.images.css 


There are also "bundled" versions of the js-zoomable-images code which 


contain all of the necessary dependencies in individual JavaScript and CSS files: 


e https://github.com/sfomuseum/js-zoomable- 
images/blob/master/dist/zoomable.images.rollupjs nttps://github.com 
/sfomuseum/js-zoomable- 


images/blob/master/dist/zoomable.images.rollup.js 


e https://github.com/sfomuseum/js-zoomable- 
images/blob/master/dist/zoomable.images.rollup.css nttps://github.c 
om/sfomuseum/js-zoomable- 


images/blob/master/dist/zoomable.images.rollup.css 
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the hummingbirds seem 
largely unconcerned by 
events 


quarter-waves 


quarter-waves 
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There is more to say about this last picture but not today. 
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the allusion of probability 


mori point 


mori point 
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sketch, 7.62cm x 3.81cm 
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drawing, 22.86cm x 25.24cm 
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drawing, 22.86cm x 25.24cm 
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triptych, 405cm x 270cm 
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triptych, 405cm x 270cm 
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triptych, 405cm x 270cm (detail) 
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triptych, 405cm x 270cm (detail) 


I should have spent more time in the textiles department at school. 
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a uniformity of application 


the same but different, something new 


the same but different, 
something new 





In May of this year I 


wrote https://aaronland. info/weblog/2020/05/26/fold/#ort 


his 


I don't have a lot to say about the drawings 
themselves. I make them. I usually publish them 
somewhere. I do it again. Five years later there are 
almost a thousand of them. 


Recently, I've been thinking about selling those drawings. The point 
of doing the work (making the drawings) is to do the work and not 
necessarily to sell the work. It would be nice to sell the work, to 
know that the work has found a home where it will be appreciated 
and to have that work pay some of the bills. I've also been thinking 
about selling digital prints of some of the drawings. More than 
anything that's what this blog post is about because I want to have 
something to point people to when I tell them, or they ask why, the 


prints are different from the original drawings. 


In between giving away artwork for free and the astronomical 
amounts of money spent on individual works at high-end auctions 
and a few select commercial galleries is the vast grey area where 
the economics of making and selling art don't always make sense. 
More often that not it costs more to produce most works of art, 
measured in time and materials and so-called "opportunity costs", 
than they are ever sold for in an artist's lifetime. Even then, even 
when priced as modestly as an artist imagines possible the work 


remains beyond the means of many. 





I think this is one reason why the idea of prints, and print-making, 
is so popular. It is the intersection, however brief, between the craft 
of an individual and mechanical reproduction. The intersection 


between effort and reward and availability and reach and audience. 


I don't necessarily believe in the primacy of the object but I do 
believe in the value of an object, and especially intentional objects. 
That's an unfashionable opinion in some circles and lots of people 
think it is outmoded and naive in a world of deep 

fakes https://en.wikipedia.org/wiki/Deepfake , Style 
transfers https://blog.google/outreach-initiatives/arts- 
culture/transform-your-photo-style-iconic-artist/ and 


generative mimicry https://github.com/LingDong-/shan- 


shui-inf . People have also been saying painting is 

dead https://www.bbc.com/culture/article/20150217-is- 
painting-dead for something like six thousand years and that's 
clearly not the case so I think there's room for everyone to be a little 


bit right and little bit wrong about this subject. 





The challenge of any print not created on the transfer medium itself 
is one of translation, one that usually feels like an exercise in 
getting "lost in translation". I haven't found any satifying way of 


capturing the qualities that I appreciate about my drawings, whether 


its the tenor of the ink, the tone of the paper, the depth of a brush 
stroke or any of the other physical properties of the work with a 
camera. In 2020 the long-standing problem of how to account for 
lighting conditions is exascerbated by so-called computational 
photography applications having an opinion about things and not 
offering much in the way of recourse. The ur-example of this, so 
far, are the stories of people in San Francisco taking pictures of 
the orange skies caused by the wild 

fires https: //www.theatlantic.com/technology/archive/2020/ 
09/camera-phone-wildfire-sky/616279/ only to have those 
skies "auto-corrected" in to a pedestrian overcast grey by their 


phones. 


Even producing prints from purely digital works, like 

prettymaps https://prettymaps.stamen.com , is difficult since 
it involves translating colours produced by light in to colours 
produced by pigment, a process that is compounded by how those 
colours sits on or are absorbed by the material they are applied to. 
Here's a picture of one of the proofs of the prettymaps installation 
made for the Talk To 

Me https://www.moma.org/interactives/exhibitions/2011/t 
alktome/objects/146211/ show, printed on a rubbery matte 
surface that refracts light as though it were passing through Jell- 

O https://en.wikipedia.org/wiki/Jello .I especially like 
this picture because I still thought I could convince the curator and 
designers to change the background colour of the exhibition walls 


from orange to white. 





























I went through a similar process for every single prettymaps 
edition https://20x200.com/collections/aaron-straup-cope 
produced for 20x200 https://20x200.com/_ .I think after an 


initial round of proofing any additional time came out of my cut of 


the proceeds and the whole process was instructive since I think 
there was an expectation, on everyone's part, that we could apply 
the same digital-to-print settings for any part of the world. The 
reality governed by the unique combination of shapes and colours 


produced by different areas of the map proved otherwise. 





There are in fact subtle differences in each of these prints but, as 
mentioned, the computational photography in my phone's camera 
application isn't much interested in showing them... 


Rather than twisting myself in knots trying to make "faithful" 
images of the work I've been trying to think about how to make 
prints of a drawing that are clearly derived from the original but 
just as clearly their own distinct work. This is what I've settled on, 


at least for now: 


e The prints will be larger than the original drawing. 


e The prints will be black and white, vectorized 


representations of the original drawing. 


e The prints will be available in small runs, probably no 


more than three to ten prints in an edition. 


e The prints will be "digitally" printed. 


The prints are digital, as in they are printed on a fancy inkjet 
printer. I would actually prefer to screen 

print https://en.wikipedia.org/wiki/Screen printing 
them on paper because of the quality of the ink and the way it sits 


on the paper but I don't have the means, or the time, to do that yet. 


It would not be unfair to say that limiting the number of prints in an 
edition is, in its own way, pretty undemocratic and perpetuates a 
model of manufactured scarcity and value that ultimately causes 
more harm than good. That might be overstating things a bit but it's 
still an argument with merit and worth discussing. I don't have an 
answer for this yet so in the meantime maybe I am just part of the 


problem? 





That the prints will be larger than the original drawing is a by- 
product of the decision to vectorize the drawings and the 
experience of having some textiles printed from smaller drawings 
this year. The photograph above shows some fabric I made from an 
index-card sized drawing and sections of the Mori 

Point https://en.wikipedia.org/wiki/Mori_ Point wall 
hanging I showed in the last blog 

post https://www.aaronland. info/weblog/2020/09/22/allusio 
n/#mori-point . That wall hanging, which measures 13.5 feet by 
9 feet was produced from an original 

drawing https://aaronland.info/orthis/171/334/619/3/ 


that is 9 by 6 inches in size. 
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Both of these were done by vectorizing a scan of the orginal 
drawing which produces a two-tone, simplified representation of 
the image and then printing it larger the original. The vectorization 
process is just pixel-counting math whose goal is to create 
contiguous areas of black or white that are smooth and curvilinear. 
It's sort of like the maths are playing a game of 

Othello https://en.wikipedia.org/wiki/Reversi witha 
pixelated image and being awarded extra points for avoiding sharp 
angles. In this way the prints are so much made of math but with 
math, as though the maths were a finish or a vanish over a painting. 


Once vectorized I could make prints of any size but I think I will 
stick to one size per edition, always larger than the original 
drawing. I enjoy seeing the over-sized lines and brush strokes, and 


the spaces between them, that are produced by this process and it 
signals a clear delineation between the original drawing and the 


print. They are the same, yet different. 
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Maybe what I enjoy about these derivative works is that they show 
me the work I really want to be making but lack the time or the 
space or the experience to do by hand. Maybe it just demonstrates 
the direction that the work is moving in regardless. Maybe it is 
something genuinely novel. What I like most about these prints is 
the uniformity of application in the way the ink sits on the paper. It 
is why I want to start producing screen-printed editions. I want to 
see thick and sticky ink squeezed through a fabric mesh and applied 


as single, uniform mass with volume and body rather than the fog 


of a million tiny dots of ink, each clinging to the paper as though 


they were hanging off the side of a cliff. 


That fog of ink, of inkjet printers and inkjet prints, is what I've got 


right now so it's what I am working with. As with the 


it's not a process 


://prettymaps.stamen.com 


prettymaps https 
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that can be applied uniformly with equal success. 
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//aaronland.info/orthis/172/936/326/9/ 


drawing https 


was easy for me to imagine it as a series of prints. I found the 


reality produced by that idea to be underwhelming. The vectorized 


print image is a pale shadow of the original drawing, unable to 


speak for itself. It has a sameness to the original drawing but it is 
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not different in its own right. 





s where things stand today. That is why the print editions are 


That 


different from the drawings they are derived from. There are a few 


editions printed and for sale but no place for anyone to purchase 


them online yet. There will be soon but I am taking each of these 


steps slowly. 
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2020-10-27 


things | have written about elsewhere 
#20201028 


Archiving social media accounts at SFO Museum -... 


Archiving social media accounts at 
SFO Museum - Take two 


Search results for “puppies” 
There are 5 results for this query, grouped by the following types: 


tweet 3 and instagram 1 and object 1 





RT @flySFO. Our Wag Brigade dags sill tke to be 
ated Ike puppies! #PatMte #NatlonalPuppyDay 


is tweet nas posted on March 23, 2016. 








This was originally published on the SFO Museum Mills Field 
weblog https://millsfield.sfomuseum.org/blog/2020/10/28/socialmedia/ ,in 


October 2020. 


Two weeks ago we updated the @sfomuseum Twitter 

archives https://millsfield.sfomuseum.org/twitter onthe Mills Field website. 
In addition to refreshing the data we also made all the images associated with those 
Twitter posts 

"zoomable https://millsfield.sfomuseum.org/blog/2020/09/14/js- 

zoomable/ "and we integrated the Twitter archive with the default search 

results https://millsfield.sfomuseum.org/search/?q=747&placetype=tweet on 
the Mills Field website. A week ago we did the same thing with the @sfomuseum 
Instagram account https://instagram.com/sfomuseum , adding eight years of 
Instagram posts https://millsfield.sfomuseum.org/instagram to the mix 
including dedicated pages for each of the hashtags that are associated with a given post. 
(We haven't added tag pages for the Twitter archive yet but we will soon.) Now that 


these archives are part of the Mills Field website we can start to more tightly link them, 
beyond just tags, with everything else in our collection. We can also geotag these 
posts https://millsfield.sfomuseum.org/blog/tags/geotagging which will be 
especially fun for things like the 

#behindthescenes https://millsfield.sfomuseum.org/instagram/tags/behindth 


escenes pictures. 


This is an extension to and a revisiting of the work we started in 
2019 https://millsfield.sfomuseum.org/blog/2019/03/06/twitter/ when we 


wrote this about the museum's social media accounts: 


It is important to recognize that Bao’s work is not simply “non-institutional 
contextualization of digitized collection objects” but an important 
contribution, one that is central to the museum’s mission. Darren’s 
comments, though, served to highlight the fact that we haven’t done a great 


job of “capturing” or “archiving” any of it [on our own website]. 


The process to import these archives isn't automated yet but I would like it to be, 
shortly. It will probably take another two or three iterations to work out the remaining 
kinks but the goal is for Bao, who manages all our social media accounts, to be able to 
request an export of the museum's data from Twitter or Instagram and upon receipt 
upload that archive to a service we control which will take care of processing images 


and indexing the posts on the Mills Field website. 





—— 


— 


ch SFO Museum 


@SFOMuseum Twitter Posts 





RT @museumofflight: We are live from the 747! https://t.co/SQfo6Snide 


This tweet was posted on September 28, 2018, 


In principle we could do this in near real-time using the Twitter API but since there is 
no equivalent service for Instagram it seems easier to standardize around working with 
the static archives that each service publishes. It fosters a practice of actively 
requesting backups of our activity on these services, as opposed to relying ona 
mysterious automated system running in the background. I also like that it mirrors our 
own practice of building services and functionality, like the Mills Field website, 
from the same open data that we 

publish https: //www.aaronland.info/weblog/2019/04/08/post/#mw19 for other 


people to use. 


The rest of this blog post is pretty technical so if that's not something that interests you 
we invite you to spend some time spelunking through almost nine years of 
Twitter https://millsfield.sfomuseum.org/twitter and 


Instagram https://millsfield.sfomuseum.org posts. 


@SFOMuseum Instagram Posts tagged #airportart 





nig a i 
mosaic #tile #behindthescenes #museummonday _#RobertRamirez #painting #brushstrokes #brush __#RobertRamirez #painting #brushstrokes s#brush 
#sneakpesk #Terminalt #paint #Hoxture #airportart #publicart #areek #paint #texture #airportart #publicart #greck 
Hclassicalgreek #Hellenic #olassicalgreek #Hellenic 
his image was posted on June 24, 2019, 
This image was p 





Jon November 16, 2018. This image was posted on November 16, 2018. 


We were able to re-use most of the same code for importing the Twitter archives to 
import the Instagram archives. Each service has its own unique quirks so there are still 
two distinct code branches but gradually, as we learn by doing, we are building up 


layers of common functionality that can be used with both services. 


Two of those layers are the go-sfomuseum- 

instagram https://github.com/sfomuseum/go-sfomuseum-instagram and go- 
sfomuseum-twitter https://github.com/sfomuseum/go-sfomuseum-twitter 
packages. These are first bits of code that we pass the Instagram media. json and 
Twitter tweet . js metadata files through in order to modify that data or append new 


properties. In the case of Instagram that means: 


e Generating and appending a media_id property derived from a post's 
image filename. 


e Generating a Unix timestamp property from a post's taken_at property. 


e Generating and appending a list of hashtags and users properties 
derived from a post's caption. 


e Generating and appending an excerpt property derived from a post's 
caption. 


These are all properties missing from the metadata that Instagram publishes. They are 
all things that SFO Museum needs to import Instagram posts but they seem broadly 


useful, in a number of scenarios, so we've made them available in code that isn't SFO 


Museum-specific. In the case of Twitter the modifications include: 


e Generating a Unix timestamp property from a post's created_at 
property. 


e Determining and appending a unshortened_ur1 property to each 
entities.url entry for a post. 


Overall, the Twitter archive metadata is more robust and comprehensive with things 
like tags and users mentioned in a post separated in to their own machine-readable 
properties. This approach is also applied to URLs and each entry in the 
entities.url array contains its own url, display_url and expanded_url 
properties. Many of our Twitter posts contain shortened URLs that we created, at the 
time, but I feel like it's important to resolve all those URLs so people can see for 
themselves where a link will take them. Our Twitter ingest code uses another library 
we've published, called go-url-unshortener https://github.com/sfomuseum/go- 
url-unshortener , to follow a shortened URL back to its source and then appends 


that value to the appropriate entities .url property. 
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In addition to making their own textiles, the Shakers crafted the related 
production tools. 


This image was posted on February 28, 2013. 


These tools are available as libraries written in the Go programming 


language https://golang.org but we've also made the functionality available as 
standalone command line applications. The approach taken with these tools follows 
work done elsewhere to process the Smithsonian's OpenAccess public data 

set https://github.com/aaronland/go-smithsonian-openaccess. . The size and 
volume of the OpenAccess data https: //github.com/Smithsonian/OpenAccess 
has prompted Smithsonian to publish that data as a series of compressed, line-delimited 
JSON records in a number of nested folders. In order to make the data a little easier to 
work with I wrote a tool, called emit https://github.com/aaronland/go- 
smithsonian-openaccess#emit , to take care of all the details of crawling the data 
and simply publish each record to 

STDOUT https://en.wikipedia.org/wiki/Standard_streams#Standard_output_ 


(stdout where it can be consumed by another process. 


Here's an example of what that looks like processing everything in the National Air 
and Space Museum collection https://airandspace.si.edu/collections as 
JSON, passing the result to the jq tool, searching for things with "space" in the title 
using the grep tool and finally sorting the results using the sort tool: 


$> bin/emit -bucket-uri file:///usr/local/OpenAccess \ 
-json \ 
-validate-json \ 
metadata/objects/NASM/ \ 


| ja ‘-[]["title"]" \ 
| grep -i 'space' \ 
| sort 


"Medal, NASA Space Flight, Sally Ride" 

"Medal, STS-7, Smithsonian National Air and Space Museum, Sally Ride" 
"Mirror, Primary Backup, Hubble Space Telescope" 

"Model, 1:5, Hubble Space Telescope" 

"Model, Space Shuttle, Delta-Wing High Cross-Range Orbiter Concept" 
"Model, Space Shuttle, Final Orbiter Concept" 

"Model, Space Shuttle, North American Rockwell Final Design, 1:15" 
"Model, Space Shuttle, Straight-Wing Low Cross-Range Orbiter Concept" 
"Model, Wind Tunnel, Convair Space Shuttle, 0.006 scale" 

"Orbiter, Space Shuttle, OV-103, Discovery" 

"Space Food, Beef and Vegetables, Mercury, Friendship 7" 

"Spacecraft, Mariner 10, Flight Spare" 

"Spacecraft, New Horizons, Mock-up, model" 

"Suit, SpaceShipOne, Mike Melvill" 


Both the go-sfomuseum-instagram and go-sfomuseum-twitter packages 
have their own equivalent "emit" tools which allow a user to take advantage of the 


code we've written without necessarily having to write custom code in Go to process 


the output. Here's what the Instagram tool looks like: 


$> ./bin/emit \ 
-append-all \ 
-expand-caption \ 
-json \ 
-format-json \ 
-media-uri file:///usr/local/instagram/media. json 


{ 
"caption": { 
"body": "In 1994, Gilbert Baker, the original creator of the rainbow flag and a team of volunteers 
"excerpt": "In 1994, Gilbert Baker, the original creator of the rainbow flag and a team of voluntee 
"hashtags": [ 
“GilbertBaker", 
“RainbowFlag", 
"ALegacyofPride", 
“gaypride", 
"lgbtpride", 
"pride", 
"LGBT", 


1, 

"users": [] 
ye 
"taken_at": "2018-09-20T03:40:04+00:00", 
"location" “San Francisco International Airport (SFO)", 
"path": "photos/201809/0ebfa6dda7247127£b67475768299db2. jpg", 
"taken": 1537414804, 
"media_id": "Qebfa6dda7247127£b67475768299db2" 





and so on 


And this is what the Twitter tool looks like: 


-/bin/emit \ 
-append-all \ 
-json \ 
-format-json \ 
-tweets-uri file:///usr/local/twitter/data/tweet.js 
[ 
{ 
"created_at": "Mon Sep 19 19:21:04 +0000 2011", 
"“display_text_range": ["0", "88"], 
"entities": { 
"hashtags": [], 
"symbols": [], 
"urls": [ 
{ 
"display_url": "bit.1ly/q8nobK", 
“expanded_url": "http://bit.ly/q8nobK", 
"indices": ["68", "88"], 
"url": “http://t.co/aGv43tHf", 
“unshortened_url": “https://www.flysfo.com/web/page/sfo_museum/exhibitions/terminall_exhibition 
} 
1, 
"user_mentions": [] 
ye 
"favorite_count": "0", 
"favorited": false, 
"full_text": “Is anyone else hot? How about an Antarctic iceberg to cool you off: http://t.co/aGv43tl 
"id": "115868023763632128", 
"id_str": "115868023763632128", 
"lang": “en", 
"possibly sensitive": false, 
"retweet_count": "0", 
"retweeted": false, 
"source": "\u003ca href=\"https://about.twitter.com/products/tweetdeck\" rel=\"nofollow\"\u003eTweetl 
"truncated": false, 
"created": 1316460064 
} 
++.and so on 
] 





There are many other steps in our import process, notably around processing images 
and making them "zoomable". Much of that process is SFO Museum-specific but 


where there are common patterns and approaches that other museums and cultural 


heritage institutions can use we'll write about them soon. 
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What's going on at the museum? We're preparing for our newest 
exhibition, “The Style of Display: Victorian Pedestals" by creating custom 
mounts for every object. This piece will be held in place by small pins set 
next to the pedestal's feet and into the case floor. First, brass rods are 
measured and cut to the appropriate dimensions for a particular object 
Then they're covered with a plastic sleeve to protect the object from the 
hardness of the metal. All of the mounts created by our staff are lovingly 
crafted and tested before being installed for exhibition. Stay tuned for more 
behind the scenes updates from the museum! 


This post was tagged #VictorianPedestals and #victorian and #pedestal 
and #behindthescenes and #sneakpeek and #museumlife and 
#preparatorlife and #arthandling 


This image wa: 





sted on May 09, 2019. 


This first stage of "prepping" the data for ingest, though, is something we probably all 
want to do so we are happy to share what we've developed so far. 


e https://github.com/sfomuseum/go-sfomuseum- 


instagram https://github.com/sfomuseum/go-sfomuseum-instagram 


e https://github.com/sfomuseum/go-sfomuseum- 


twitter https://github.com/sfomuseum/go-sfomuseum-twitter 


e https://github.com/sfomuseum/go-url- 


unshortener https://github.com/sfomuseum/go-url-unshortener 
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untouchable touching 


the elephant in the room: build it or buy it? 


the elephant in the room: 
build it or buy it? 
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These are my slides from the Bring Your Own Device and In-Hand 
Interactives: How Covid-19 Forced Innovation in Our 
Interactives https://mcn2020virtual.sched.com/event/d£2Z7/b 
ring-your-own-device-and-in-hand-interactives-how-covid- 
19-forced-innovation-in-our-interactives session at the 
MCN 2020 (virtual) 

conference https://mcn.edu/conferences/mcn-2020- 

virtual/ .I was paired to present alongside David 

Zlatic https://www.bowtiedave.com/ from the Cincinatti 
Museum Center hnttps://www.cincymuseum.org/ .I1 didn't know 
David before this event and we spent the months leading up to our 
session getting to one another and talking through the issues and 
our experiences with them. Whether or not our session was a 
success it was a delight getting to know David in the process. This 
is what I said. 


I'd like to start with a riddle. 


if an elephant is%n,tha room 





If an elephant is in the room. 


if an elephant isn tha room 
jo) 0) mateo) als 


for Tao fom-TaN ani iarem-lerelelanis 





But no one can do anything about it. 


if an elephant isn tha room 
lo] 0) mi alee) als 


fer Tao fom-TaNaraiiarem-lefelelaris 
is it really there? - 





Is it really there? 
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Cap-ex versus Op-ex 





I'm starting with this riddle because the question of how digital 
initiatives are funded, whether they are budgeted as one-time 
capital expenses or ongoing operational expenses, is where most 
museum-related technology discussions end up. This is especially 


true of discussions about whether to "build or buy". 


I mention this because I think it is the root cause of so many of our 
challenges trying to do anything labeled "digital" in the sector. A lot 
of what I am about to say crashes up against some uncomfortable 
and unpleasant realities about the way the sector operates. I am not 
going to answer the op-ex versus cap-ex problem today but I also 


think it's important to admit it is real and present. 





My own feeling is that, in practice, capital projects are strung 
together for years on end to the point where they are functionally 
indistinguishable from daily operations. 


They are capital expenses in name only. 


The day-to-day reality is that they are essentially operational 
expenses but with the luxury and caché of larger budgets and none 
of the responsibility or hassle of actually operating anything or of 


managing the people necessary to do so. 





This bothers me because it's money that could be better spent by 
hiring people, and then being able to afford to keep them around, to 
build and nurture the kinds of digital initiatives that the sector says 


it needs and wants. 


It is sometimes said that technology is the connective tissue that 
binds people. For example we are all able to gather 

here https://mcn.edu/conferences/mcen-2020-virtual/how- 
to-men-virtual/ today because of tools like Zoom and Slack. At 
the same time people are the connective tissue that bind 


technologies. 


What I mean is that there is a limit to what software can do on its 
own. At some point, in order to meet the specific demands of a 
project, someone needs to sit down and write the software that tells 
all the other software and complex systems what to do. These are 
the people the cap-ex / op-ex dilemma tells us we can't afford. 


If you believe that to be an intractable problem then the rest of what 
I am about to say will probably sound like someone shouting at 


the sky https://www.youtube.com/watch?v=tJ-Livk4-78 





I believe we can't afford to not tackle the staffing problem because 
some amount of in-house development is the only way we will 
make our digital initiatives sustainable beyond any single capital 
fund-raising cycle. 


But there is also a need to change the way we do that in-house, and 


in-sector, development. 


Historically, one of the things that has characterized software 
projects built to be used by more than a single institution is that 
they are overly broad. They try to do too much and account for too 
many customizations necessary to account for too many different 
institutions. They are too much of everything and not enough of 
anything. 


We need more small, focused tools that don't try to be all things to 
all people, all the time. 


AS a very practical first step to finding a way out of the build- 
versus-buy hole we've dug for ourselves we need to develop a new 
practice for the way we build the tools we use internally so that 
they might be split in to smaller pieces that can be shared by as 


many people as possible externally. 
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But first... 2020. 
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One of the things that's happened this year is that the long bet the 

museum sector has made around touchable surfaces as the principal 
interaction model for visitors in our galleries is facing an existential 
crisis. Until there is some resolution to COVID-19 all the touchable 


surfaces we've invested in are untouchable. 


; bring.your own 
~ (touchable glass) 





This has led a number of institutions to revisit strategies centered 
around the idea that visitors will "bring their own device", namely 
their phones. That's understandable but it doesn't answer the 
question: How then does a person's device interact with your 


museum? 
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If the goal is for a museum to interact with and trigger an 
individual's device, one it doesn't control, how precisely does that 
conversation get started, nevermind what happens on that device 
afterwards? This is the part where we have to stop thinking about 
what might be possible, in some hypothetical future-world, and 


instead focus on what's actually within our reach today. 


fo | mexele(-1-) 

nie 

bluetooth 
computer vision 


motion tracking 
voice assistants 
mixed reality 





Here's a list of available technologies in 2020 that can be found on 
most people's devices for triggering different kinds of interactions 
beyond touch, ranked roughly in order of complexity and 
sophistication. With the exception of barcodes, which I guarantee 
you are more complicated than you think, each item in this list is an 


incredibly ambitious and nuanced ecosystem in its own right. 


fo | mexele(-1-) 

nie 

bluetooth 
computer vision 


motion tracking 
voice assistants 
mixed reality 

in a web browser! 





Ideally, we'd like to be able to have access to all of these things in a 
web browser so we don't have the burden of supporting multiple 
platforms or older devices or the hassle of publishing things to an 
"app store". 


fo | mexele(-1-) 

nie 

bluetooth 
computer vision 


motion tracking 

voice assistants 

mixed reality 
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But that's not likely to happen any time soon. 


Most of these technologies are still entirely dependent on, or often 
handicapped by, vendor platforms in order to operate and all of 
them demand significant amounts of time and expertise to 
configure. There are some exceptions but, by and large, these are 
technologies that are still only available to so-called "native" 


applications. This can be a discouraging realization. 


Birth 
of the 


Barcode y oN 
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What, then, can we learn from the Digimarc experience that David 


has described? 


Briefly, the Cincinatti Museum Center migrated all of their existing 
in-gallery interactive experiences to a mobile website and used 
Digimarc codes embedded in wall labels and signage throughout 


the museum to open those experiences on a visitor's phone. 


The first is that I think Cincinatti's decision, in this case, to use a 
vendor solution was the right one. It made sense given the 
institutional capacities and constraints. The second is that it points 
to something the sector needs. It is also something that the sector 


can and should develop for itself. 
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Consider what Digimarc does: It embeds an identifier in a 
photograph that triggers an action or an interaction. In 2020, this is 
actually the kind of thing that we could build by and for ourselves. 
We don't even need to embed anything in a image so much as 
simply be able to recognize an image and associate it with an 


identifier. 


Importantly we don't need to do this for all the possible images in 
the world only for the images that we want to include in our wall 
labels or our signage. We don't need to see all things we only need 
for certain things to be minimally viably recognizable. This is well 
within the capacity of a handful of institutions to develop and 


everyone else to use and improve. 


Just as importantly, I am not suggesting that we write software to 


replicate Cincinatti's in-gallery experience. 


I am talking about the ground-level functionality of using an image 
as a trigger for subsequent interactions, to bridge a physical space 
with its online counterpart that a visitor interacts with on their 


device. 


minimally Viably 
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I was part of the team at the Cooper Hewitt that designed and 
launched The 

Pen http://www.aaronland. info/weblog/2015/04/10/things/# 
mw2015 .The Pen was an interactive stylus with an embedded NFC 
reader that allowed people to collect objects on display by tapping 
their pen to a wall label which contained an NFC tag with that 
object's ID embedded in it. 


At its core the Pen was about making every object in the museum 
addressable http://www.aaronland.info/weblog/2015/03/16/m 
ention/#breaking-up and of broadcasting that address in order 
that a variety of applications might do something with it. That was 
the ground-level functionality from which everything else was 


derived. 


We invested a lot of time and money in the Pen but it was always 


possible to implement the same functionality using the Cooper 


Hewitt's API https://collection.cooperhewitt.org/api 
and an Android device, which have supported reading NFC tags 


since well before the Pen was launched. 


We invested in the Pen partly because it wasn't possible to scan 
NFC tags on iPhones in 2015 but principally because its design 
promoted particular kinds of behaviours we wanted to encourage in 
the galleries. Specifically, we wanted people to understand that they 
had license to interact with the museum and to have a "heads up" 


visit, and not spend all their time looking down at their phones. 


But we also went to great lengths to ensure that the underlying 
functionality of the Pen, that each object was addressable and 
broadcast its address over NFC, remained open and untethered 


from our own very opinionated application of that functionality. 





Like a lot of museum interactives the Pen was promptly removed 
from the floor in March of this year as a precautionary measure to 
prevent the spread of COVID-19, 


Around the same time I got my hands on an NFC-enabled iOS 
device (they finally exist now) and decided to see whether it would 
be possible to implement something like the Pen as an iOS 
application https: //aaronland. info/weblog/2020/06/16/revi 
siting/#pen . Here's what that looks like, complete with spelling 
mistakes because I filmed this demo before finishing my first cup of 
coffee. 
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Once I got an iOS application working for the Cooper Hewitt 
collection I decided to see if I could use it with another museum's 
collection. This is a video of me using my "bring your own Pen" 
device to collect objects from the Metropolitan Museum of 

Art https://aaronland. info/weblog/2020/07/13/experience/ 


#remembered 


The Met doesn't have NFC tags embedded in their wall labels so 
this might seem like a purely academic exercise but it does prove 
the point that this an interaction model which is not bound to any 


single institution or experience. 





I mentioned that all of this has been possible to do with Android 
devices since the end of 

2010 https://www.androidcentral.com/gingerbread-feature- 
near-field-communication . It's also possible to program 
Android devices to act as though they are dynamic NFC 

tags https://millsfield.sfomuseum.org/blog/2020/11/09/nfe 
clock/_ . This is a short video showing an application that 
publishes a new NFC tag containing the current date and time 
every second https://github.com/sfomuseum/android-nfc- 


clock , being read by an iPhone. 





The Met doesn't have NFC tags embedded in their wall labels. Most 
museums don't either. SFO Museum, where I work, places most of 
its wall labels on slanted rails six inches behind glass. Even if we 
wanted to put NFC tags in our labels no one would be able to read 


them because they would be too far away. 


So as I've been thinking about this idea of minimal viable 
addressability I started to think about other ways that an object 
might broadcast its 

presence https: //aaronland. info/weblog/2020/07/30/broadca 


st/#effect 


This video show two phones, each running the "bring your own 
pen" application. The phone on the left is configured to display a 
random object from a variety of museum collections and broadcast 
that object's identifier as a Bluetooth Low Energy advertisement. 


The phone on the right is configured to read tags and collect 


objects, as usual, but instead of trying to read NFC tags it looks for 
and reads Bluetooth Low Energy advertisements. 


None of this is really about specific technologies, like Bluetooth or 
NFC. It's about thinking of ways that things are addressable. It's 
also not about what happens with those identifiers. As you can see 
this application doesn't do very much. It is about identifying and 
packaging the technical plumbing necessary to enable the basic 
interactions, the first steps, that we need to do everything else. 





Before COVID-19 SFO Museum was working on its own touch- 


based interactive application, to be deployed in the terminals. 


It's a plain-vanilla web application that is run inside of a native iOS 
application running on an iPad and mirrored to an external monitor. 
This is a pretty common pattern for a lot of applications so we're 
not doing anything revolutionary here. 


We opted to wrap the web application in an iOS application, rather 
than using a cross-platform framework like Cordova or Electron, 
because there are still a few things that can only be done natively. 
In our case: Displaying, and syncing, different content from the 


same application on two different screens. 





Here's a simplified view of what that looks like. Do you notice the 
yellow box marked "javascript" in the middle? I'll come back to 


that in a moment. 





There are two important reasons for developing the application 
itself using web technologies. The first is the ease and speed of 
development and being able to test things in a web browser. The 
second is that we know that whatever else happens in Apple's 
ecosystem our application will still work in a web browser. In fact 
the guts of this application are already part of our 

website https://millsfield.sfomuseum.org/map/ 





These boxes, which are all the same web application, are really the 


only SFO Museum specific parts of what we've been developing. 





In iOS, there is a bridge for communicating between the web 
application and the native application using 

JavaScript https://developer.apple.com/videos/play/wwdc20 
20/10663/ .For example, the application I've been describing is 
also meant to run offline so we using some native iOS functionality 


to make that possible. 





Our goal is to treat this as a fast, cheap and reusable template for 


building interactive installations. 


I am fond of telling people that we have a developed a system for 
interactive displays with minimal hardware and stable costs, that 
works both online and offline, and that we can deploy to any four- 


by-four foot space at the airport. 


The only question should be: What do we want the next interactive 
to do? 


It's worth mentioning that what's interesting about this isn't so much 
that it's an iOS application or that it's running on an iPad. There are 
specific reasons why we chose these platforms but the same thing 
could be done with others. What's interesting to me is a model for 
developing sophisticated interactive applications and identifying 


the separation of concerns between the applications themselves and 


all the plumbing necessary to run them. 


We're planning on open-sourcing this 


work https://github.com/sfomuseum/ sometime next week. 





In 2020, the problem with deploying iPads in a public setting is that 
no one wants to touch them. If people can't, or won't, touch an iPad 
where touch is the principal means of controlling an application is 


there really an application anymore? 


At SFO Museum we have started to experiment with gesture 
controls, using the built-in motion-tracking functionality that has 
become available since the release of iOS 14. Software systems for 
gesture controls have existed for a while but they are often 
complicated, expensive or both. What's different here is that they 


come preloaded in the operating system now. 


The previous application I've been discussing has some pretty 
involved interactions so we're starting with something a lot simpler 
first. We are starting with a basic gallery application and working to 


add rudimentary next and previous gesture controls. 


It's early days still, and there are lots of bugs left to fix, but we've 


proven that it can work. 





The video I just showed is a native iOS application but our plan is 
to create a hybrid application, similar to the one I showed before, 
that will allow us to use native iOS code to track basic gesture 
controls and then use the Javascript bridge to relay that information 


back down to a bespoke web application. 





Here's another way of looking at that same model. 


The point I want to make is that things like gesture controls are 
complicated enough, all on their own. They only become more 
complicated the closer you get to the implementation details and 
that complexity is multiplied again by the demands that each 


museum's unique needs and requirements place on things. 





Here's another way, still, of looking at that model. 


The yellow box at the top is your museum. Your museum is unlike 
any other museum. It is unique and that character is captured in the 


expression of its experiences. 


The yellow box in the middle are the few places where there is 


actually overlap, interpretative or otherwise, between institutions. 


The stuff in the orange box, in this case gesture tracking, is the 


common ground that we are all building on. 


The things in the orange box are the standardized materials that we 
all use to make things possible. You and I may have very different 


houses but they were probably both built with two-by-fours. 


Those two-by-fours are the orange box. 





The argument I am trying to make is that when we, as a community, 
have tried to develop shared infrastructure we have spent too much 
effort trying to work around the yellow box at the top of this stack 


and not enough on the orange box on the bottom. 


If we're going to try and pool our resources then we are better off 
focusing on the things that look like two-by-fours than our 
respective homes. This was already a problem before COVID-19 
but it's so much worse now that our principal means of interaction — 


touch — is limited or entirely unavailable to us. 


We are faced with the prospect of replacing that model using 
complicated technologies that don't enjoy the same maturity or 
levels of deployment and facility that touch-based interactions do. 
We are being asked to do these things at a moment where the time 


and budgets do to them are in short supply. 





Throughout this talk, I've been trying to demonstrate two things: 


One is actual working code implementing alternative approaches to 
an interaction model we can no longer take for granted. A lot of it is 
rough around the edges. That's not on purpose but it does serve to 
highlight the idea that we need to get used to sharing, evaluating 


and contributing to work in progress. 


Second, a practice of doing the extra work to enforce strict 
separations of concerns in our applications so that we might better 
identify, extract and share common pieces of functionality where 


they exist. This is the crux of my argument. 


No one has the time or the capacity to support the full weight of 
anything other than their own museum or institution. But maybe we 
have just enough time to grow and nurture a common kit of parts 


that can be re-used and adapted by and for individual organizations. 


It may be too soon to imagine that we can make everything easy 
but maybe we can start to make more things at least possible. 


I recognize that many institutions don't have the staff to do any of 
this work yet. That is why I started with the cap-ex versus op-ex 
riddle. That is the larger question we need to solve, in whose 


shadow everything else sits. 


thank you 


@thisisaaronland ~~~ 
@sfomuseum 





A lot of what I've been talking about is aimed at institutions that do 
have technical staff. 1 want those of us who are able to support 
technical staff, whether it's one person or a dozen people, to work 
to improve the way we do things. I want us to do this in order to 
demonstrate to the rest of the sector, and in particular to the boards 
and directors of institutions who are skeptical of the value of in- 
house staff, that it is worth building things ourselves rather than 


always buying from someone else. 


Thank you. 
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skeptics 


Where Are You Now, Mr. Big Balls? 


Where Are You Now, Mr. Big 
Balls? 
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The last batch of drawings of Mr. Big 
Balls https://www.aaronland. info/weblog/2019/03/19/signs/ 
#mrbigballs were posted over a year ago. We still haven't seen 


him around the neighbourhood since then. Lately I have started to 


wonder whether Mr. Big Balls was a kind of Greek metamorphoses, 
like when the goddess Athena shows up in stories in the form of an 


eagle. 
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so you wanted to be present 
at the moment of creation 


Wish you were (not) here, 2020 


Wish you were (not) here, 
2020 
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Like the "San Francisco" postcards 


year https://www.aaronland.info/weblog/2019/12/31/koolai 


d/#postcards nothing here should be confused with a measured 


the story I 


and nuanced discussion. I remain uncertain that this is 


want to remember but it is the story I told at the time. 
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